MongoDB document version update issue with JaVers

396 views Asked by At

I was using Javers for mongoDB document versioning with springboot. It provides essential functionalities for versioning such as separate history collection called jv_snapshots, changed field list in Entity or ValueObject model for their versions. But I found an issue relevant to valueObjects, but not entities. As you know, the difference between entity and valueObjects is the unique id that identifies the entity, but valueObjects don't have such Id to identify their versions. Refer the following examples as I observed this issue in my use case.

Let's take the following Entity and valueObject models for versioning.

Invoice.java

@TypeName("invoice")
public class Invoice {

    @Id
    private long invoiceId;

    private String userName;

    private String userId;

    private List<ItemModel> items;
}

ItemModel.java

public class ItemModel {

    private String itemNo;

    private String description;

    private String brandId;

    private String packId;
}

ER Diagram (Simplified)

enter image description here

For initial invoice document creation, javers create relevant items inside the actual invoice document as separated history documents having INITIAL version type and 1 as the version. And the issue is that each of these item documents carry globalId_key marked with its array index position. This globalId_key identifies each item document unqiuely. As a result, if an UPDATE is going to happen to an invoice, then items inside it going to be compared with the INITIAL item history documents based on the array index.

Refer the following example.

Let's say only the userName relevant to the invoice changed in UPDATE version having all the items shuffled without any change in items as in the following diagram.

enter image description here

In this case, javers will create 3 separate history documents for the items having globalId_keys as follows based on the array index.

  1. invoice/123#items/0
  2. invoice/123#items/1
  3. invoice/123#items/2

As a result, during the update phase, javers will again create 3 separate history documents for items due to the comparison based on the array index. But it shouldn't happen, because items don't contain any change from the initial version except the shuffling inside the array.

Is there any possibility to avoid this issue with javers, or is there any alternative ?

1

There are 1 answers

2
Bartek Walacik On BEST ANSWER

If you don't care about ordering, change List to Set in the model. Alternatively, you can configure Javers to use the ListCompareAlgorithm.AS_SET feature.

In Spring Boot, you can enable it by setting javers.algorithm: AS_SET in your application.yml.

see https://javers.org/documentation/spring-boot-integration/#javers-configuration-properties