Traversing relationships

[bestage]

At the moment traversing relationships is not possible with the AuditQuery.
Condition one can impose on the associated objects is "relatedId".
For example if I would like to impose further restrictions on the child object, I cannot.

I know this is on your roadmap, but how long do you think we will still have to wait for this functionality?

We are in a situation that we have specific business logic which means that some restrictions/conditions are to be imposed not only on the parent object itself but also on some atttibutes of its children. I suppose if traversing relationships had been available, that wouldn't be any problem to do.

How complex would be to add this functionality to envers?

Besides, how do you assemble your object graphs e.g. in the the EntitiesForRevision query?

[bestage]

"bestage" wrote:
At the moment traversing relationships is not possible with the AuditQuery.
Condition one can impose on the associated objects is "relatedId".
For example if I would like to impose further restrictions on the child object, I cannot.

I know this is on your roadmap, but how long do you think we will still have to wait for this functionality?

We are in a situation that we have specific business logic which means that some restrictions/conditions are to be imposed not only on the parent object itself but also on some atttibutes of its children. I suppose if traversing relationships had been available, that wouldn't be any problem to do.

How complex would be to add this functionality to envers?

Besides, how do you assemble your object graphs e.g. in the the EntitiesForRevision query?

I have finally debugged envers and checked the sql code generated by envers through hibernate.

Now I see how it's working. The principle of revisions as versions of an object (or an object graph) in time is really simple but yet very powerful. Thus you avoided comparing dates or timestamps when assembling your object in the EntityAtRevision query. You simple assume that the maximum rev.number smaller than the given one and not the deleted one is your candidate.
Well done.

[kossmo]

Hello,

I'd like to thank you for this great software. We had started to build our own solution for versioning and found Envers in the middle of this. It already solves many of our issues. It just happens that one of the requirements for us would be the ability to specify an condition on a property of an associated entity (also traversing more than one association).

Henry, have you done some further research in how this could be done? I would be willing to help, but I'm not sure where to start. Is this feature planned for some specific future version? I've seen that in JIRA it's still "UNSCHEDULED".. (http://opensource.atlassian.com/projects/hibernate/browse/HHH-3555)

What's a good starting point for this feature in the code?

[kossmo]

I'd really like to help working on this problem. In our approach to versioning we add additional columns to the original tables and we have to create association classes for all the association more or less by hand. Using filters we can then isolate the latest or a historical version. There are a lot of problems getting the hibernate mapping right with the additional versioning info in the composite key and we could get around that, if we used your solution.

I've started looking around in envers code, but I cannot make out the source code that handles the matching of relatedId. Where can I find this? And why does the same approach not work with the other fields?

regards,

Tim

[adamw]

Hello,

to be able to create queries which traverse relationships and are effective you would need an additional "end revision" column. Adding this feature without this would be (I think) quite complex and with poor performance.

So there are in fact three steps to solve this problem:

* store the end-revision column

* use this information when executing normal queries

* extend the query system to be able to traverse relations

The tasks are in JIRA, but unfortunately I didn't yet get the time to work on them.

The matching of relatedId is done (if I understand you correctly) using IdMappers, as they contain the knowledge about how the ids are named etc. So they are also responsible for creating the right queries.

Adam