Revert Functionality

[Felix Mayerhuber]

Hi @all!

The revert functionality for commits is now implemented. However, it
should be tested by the industrial team before it is merged in order to
check if the new feature behaves correctly for their needs. The branch
with this functionality is located here:
https://github.com/Arcticwolf/openengsb-framework/tree/OPENENGSB-3631

Pls let us know if the functionality is fine and it can be merged with
the master.

For the querying of commits, a new object is introduced, the
CommitQueryRequest object. This object encapsulates the possible
parameters for a commit query and so it is easier to use and less error
prone than using a HashMap for the parameters. If you like what you see,
I want to do the same for the normal model queries, so that we can
replace there the parameter HashMaps with own objects which make the
code above it all more readable. Pls provide some feedback for that.

Kind regards,
Felix

[Felix Mayerhuber]

forgot to tell that the changelog is written down in the JIRA Issue: http://issues.openengsb.org/jira/browse/OPENENGSB-3631

Kind regards
Felix

[Michael Petritsch]

Hi,

thanks for the changes. Looks very good so far except for the method
getRevisionsOfMatchingCommits. I think we had a misunderstanding
there. Returning just a list with revisions without any additional
commit metadata isn't enough. This should return at least enough info
so a normal user can decide to which commit to revert to. He won't be
able to do that with abstract revision numbers. So at least committer
and timestamp is needed here and is there something like a commit
message? Just the number of inserted, updated or deleted models
(without the acutal models appended) would also be nice, if it does
not have a large performance impact. What do the fields 'context' and
'deletions' in the class JPACommit mean exactly. Context sounds
potentially useful too. And the domainId/connectorId/instanceId of
EKBCommit could be also very useful for orientation.

br

> --
> You received this message because you are subscribed to the Google Groups
> "OpenEngSB developer discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openengsb-de...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Felix Mayerhuber]

Hi,

ok so there was a misunderstanding here. I thought I asked you that
before. So what you want is that the getRevisionsOfMatchingCommits
returns a list of "EKBCommitMetaData" which contains interesting meta
data to the commit besides the revision.

Committer, timestamp, context, domainId, connectorId and instanceId is
very easy to add to this object. I'm not 100% sure about the number of
inserted, updated and deleted models, since I suppose that this will
have a noticeable performance impact.

Context saves the contextId which was active when the commit has been
done (The value is retrieved by
ContextHolder.get().getCurrentContextId()). Deletions holds all
EDBObject identifiers of the objects which has been deleted in that commit.

How do you like the CommitQueryRequest object for initiating EDB/EKB
requests? As I mentioned before, I think about using some similar
construct for the querying of models, so it would be interesting to know
how you think about it.

Kind regards,
Felix

[Michael Petritsch]

Hi,

On Fri, Aug 2, 2013 at 7:30 PM, Felix Mayerhuber
<felix.ma...@gmail.com> wrote:
> Hi,
>
> ok so there was a misunderstanding here. I thought I asked you that before.
> So what you want is that the getRevisionsOfMatchingCommits returns a list of
> "EKBCommitMetaData" which contains interesting meta data to the commit
> besides the revision.

yes, such a list would be perfect.

>
> Committer, timestamp, context, domainId, connectorId and instanceId is very
> easy to add to this object. I'm not 100% sure about the number of inserted,
> updated and deleted models, since I suppose that this will have a noticeable
> performance impact.

would it be possible to add a comment field or something like that to
a ekb/edb-commit (and EKBCommitMetaData)? then we could just add the
number of signals (and other information the user might request in the
future) manually in the comment and it wouldn't really have a
performance impact. Just like the comment in a git-commit for example.
An EKBCommit.setComment(String comment) method or something similar
would be great.

>
> Context saves the contextId which was active when the commit has been done
> (The value is retrieved by ContextHolder.get().getCurrentContextId()).
> Deletions holds all EDBObject identifiers of the objects which has been
> deleted in that commit.

ok the contextId is also interesting info for the MetaData. the list
of deletions is not required. (this can be obtained with the
loadCommit method anyway)

>
> How do you like the CommitQueryRequest object for initiating EDB/EKB
> requests? As I mentioned before, I think about using some similar construct
> for the querying of models, so it would be interesting to know how you think
> about it.

I like the CommitQueryRequest. Looks simple to use and doesn't require
complex parsing or regex checks. Has basically everything we need atm.

For a Modelquery I think it would not work that well on the first
look, if you want to implement disjunction-support someday since such
a request is just a conjunction of the class' fields.

br

[Felix Mayerhuber]

Hi,

I've implemented now this list. I will also add a comment field to the
commits. As far as I remember we had it once and deleted it since no one
used it ^^, so no big deal.

About the model query request object: The thing I think about is, that
it is now pretty hard to differentiate against which information someone
queries. E.g. you need to know that the model oid is in the model with
the key "edbId" or use the constants for that. I think building an own
object which encapsulates the query parameters and also provides methods
for this "special" fields would be much easier than just a HashMap. I
will think about it and provide a more detailed concept about it. I
think its easier to discuss about it, when it is not only in my head ^^

Kind regards
Felix

[Felix Mayerhuber]

Hi,

now I've also added the comment field to the commits and the CommitMetaInfo class. So the revert function should be fine from your point of view?

Kind regards,
Felix

>>>> email to openengsb-dev+unsubscribe@googlegroups.com.

>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OpenEngSB developer discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to openengsb-dev+unsubscribe@googlegroups.com.

[Michael Petritsch]

Hi,

yes, looks fine now, many thanks. :)

br

On Fri, Aug 2, 2013 at 9:18 PM, Felix Mayerhuber

>> >>>> email to openengsb-de...@googlegroups.com.

>> >>>> For more options, visit https://groups.google.com/groups/opt_out.
>> >>>>
>> >>>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "OpenEngSB developer discussion" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an

>> >> email to openengsb-de...@googlegroups.com.

>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenEngSB developer discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to openengsb-de...@googlegroups.com.