While I was working on OLMIS-6358 I noticed that because we are using a composite primary key for Orderable and FTAP resources which contains
versionId fields, Javers also use the same primary key to monitor changes in the resource.
The first issue is that currently the
GET /auditLog endpoints for those resources are broken because Javers is not able to find changes only by providing the
id field. This is because for those resources the
id field is only part of the primary key. Solution for this particular issue could be to add
versionId query parameter to endpoints but this solves only one issue and there is another one which will occur when we fix the issue with endpoints.
Another issue is that Javers treats each version of a resource as a new resource. In other words, if for instance there is an orderable in the system with the initial version and we provide changes that will create a new version, Javers will treat those two versions as separate resources. I would say that this is incorrect behavior. I tried to fix this issue by adding Javers
@id annotation on the
getId method but it seems like Javers ignores this annotation because it sees other annotations from JPA.
In the end, we can try to fix those issues or rethink if we really need Javers for those resources. If I remember correctly, we provided Javers for OpenLMIS resources to be able to say who and what have been changed in the given resource but for orderables and FTAPs we have our internal solution and we are able to say what changes were provided. We are not able to say who provided changes but it should be quite easy to provide this information and return it in DTOs.
What are your thoughts?