| Hello everyone,
In our project we use the EnversRevisionRepository of spring-data-envers to request our revisions. Right now we just implemented a REST API to get the information to other systems.
Now it happened that our test engineer found an unexpected behaviour when requesting a wrong and not existing combination of an ID of the entity and the wanted REV.
| id |
REV |
REVTYPE |
NAME |
DESCRIPTION |
| – |
– |
– |
– |
– |
| 8 |
9 |
0 |
first entry |
first entry description |
| 8 |
19 |
1 |
first entry update |
first entry extended description |
| 17 |
18 |
0 |
second entry |
second entry description |
| 17 |
20 |
1 |
second entry udpate |
second entry description |
So if you request a special combination of ID and REV like ID = 8 and REV = 18 , which is obviously wrong but technically possible, you receive the a mix of the revision meta data information and a wrong entity revision.
The reason seems to be a subquery which is generated by the call of
'org.hibernate.envers.strategy.DefaultAuditStrategy.addEntityAtRevisionRestriction'
the subquery is this one
```
select max(entity1_ .REV)
from schema.SomeEntity_AUD entity1_
where entity1_.REV <=18 and entity1_.id = 8
```
In this case the result of the subquery is the REV 9, which is correctly an existing entry belonging to the entity with the ID = 8 and it has an REV <= 18.
| id |
REV |
REVTYPE |
NAME |
DESCRIPTION |
| – |
– |
– |
– |
– |
| 8 |
9 |
0 |
first entry |
first entry description |
But we would have expected a result like a zero size list or an exception, because of the invalid combination of ID and REV.
The result of such a wrong combination is not predictable and it returns the first revison found which has a REV smaller then the wanted one.
If the REV in the query would be 21 instead of 18 you would get the updated revision of the entity ID = 8
| id |
REV |
REVTYPE |
NAME |
DESCRIPTION |
| – |
– |
– |
– |
– |
| 8 |
19 |
1 |
first entry update |
first entry extended description |
I know that usually the process would be requesting all possible revisions to an entity and then select the wanted revision from this list. But with the REST API of us you just dont know at the moment whether it is a valid combination or just the one the subselect found. Maybe we have a wrong understanding of the use here, but to us it seems to be a bug at the moment. What is your opinion about this behaviour ? |
