Ran into what I believe is a bug or at least a shortcoming with Javers.
We have two applications that use a shared database.
The first application is responsible for creating the database entities.
The second application is a batch processing application that reads and updates the same entities after performing a long running batch process, eventually updating the entity with the results of that process.
The first application uses the audit log of the entity (provided by Javers) to show the various changes to the entity over time.
Here's the issue:
In the first application the package name for the entity is something like this:
a.b.c.Entity
In the second application the package name is slightly different:
a.b.c.d.Entity
The different package naming was done to follow the naming/package conventions of the two applications.
Otherwise the two mappings of the entities are identical. Both applications are set up to use Javers for audit logging.
We observed that the changes to the entity performed by the batch application were not showing up in the audit log in the main application.
As it turns out, Javers relies on the entity package name to identify the object recorded in the j_snapshot table. So we had two separate audit trails for the same database table: one for a.b.c.Entity and another for a.b.c.d.Entity even though they shared the same collection and id.
We were able resolve the issue by using the same package for the entity in both applications. This works but it seems rather brittle to me.
A similar scenario could arise if for whatever reason the package name of the mapped entity was changed. All history of the original entity would be essentially lost when looking up the audit changes for the newly renamed entity.
Is there a way to configure Javers to avoid this or are we tied to using the package name in the global_id_key and the object's id as an identifier?
As it's said in Javers' docs. You should use @TypeName:
@TypeName("Person")
class Person {
@Id String name
String position
}
https://javers.org/documentation/domain-configuration/#entity
@TypeName — a convenient way to name Entities and Value Objects. We recommend using this annotation for all Entities and Value Objects. Otherwise, Javers uses fully-qualified class names in GlobalIds, which hinders refactoring classes committed to JaversRepository.
Important! All classes with @TypeName should be registered in JaversBuilder using withPackagesToScan(String)
https://javers.org/documentation/domain-configuration/#supported-annotations