Envers: Please support nested criteria in revisionsOfEntity queries
Description
Activity
Russell Morrisey May 14, 2020 at 7:07 PM
What can I do to help this change move forward?
Thanks
Russell Morrisey February 6, 2020 at 10:52 PM
I have smoke tested this feature and integrated it into my app using a local snapshot build. I would like to use it in my next release, if possible.
It looks like the Travis build is held up by code style formatting issues. I have submitted a PR against Chris' fork with IDEA formatting fixes that should correct the build issues.
Can this PR be merged?
Thanks!
Russell Morrisey January 23, 2020 at 7:53 PM
Thanks a lot for your help! This will be a big performance boost for the audit history UI on my project.
Russell Morrisey January 23, 2020 at 7:36 PM
Scratch that! It was a mistake in my client code. Sorry.
It turns out that if I add the subquery after the query is executed, it doesnāt affect the query result. :)
Once I fixed that issue, it produced the expected output.
Russell Morrisey January 23, 2020 at 7:32 PM
I was able to work around this limitation by using two audit queries instead of one. The second query just looks up the revisionsForEntity using the IDs of the entities returned from the first query:
def auditQuery = queryCreator.forRevisionsOfEntity(gdc, false, true). add(AuditEntity.id().in(settingIdList)). addOrder(AuditEntity.revisionNumber().asc())
This failed my regression test. Iām analyzing the data & generated SQL to try to figure out why.
Details
Details
Assignee
Chris CranfordReporter
Russell MorriseyComponents
Fix versions
Priority
Major
Please support the traverseRelation operation for RevisionsOfEntityQuery!
The current implementation throws an UnsupportedOperationException:
public AuditAssociationQuery<? extends AuditQuery> traverseRelation(String associationName, JoinType joinType) {
throw new UnsupportedOperationException( "Not yet implemented for revisions of entity queries" );
}
My application aggregates multiple records to present information to the user, so viewing the history of only one entity instance doesn't make sense for my use case. Users have asked for the ability to filter and sort history based on properties which I mapped to nested entities.
For now, I will have to filter the query results in client code, which is not very efficient.
Thank you!