Javers ne signale pas les références des changements dans la hiérarchie objet

Question

problème Déclaration

J'expérimente avec la capacité de Javers 3.5.1 faire rapport des changements qui se sont engagés. Il semble que les changements ne sont signalés que s'ils sont primitifs; lorsqu'une référence d'objet change dans la hiérarchie d'une entité, les modifications ne sont pas rapportées.

Exemple

Voici un exemple:

Javers javers = JaversBuilder.javers().build(); 

    RegexRegisteredService svc2 = new RegexRegisteredService(); 
    // Set a reference to something 
    svc2.setUsernameAttributeProvider(new DefaultRegisteredServiceUsernameProvider()); 
    svc2.setId(345); 
    javers.commit("345", svc2); 

    // change the reference 
    svc2.setUsernameAttributeProvider(new AnonymousRegisteredServiceUsernameAttributeProvider()); 
    javers.commit("345", svc2); 

    List<Change> changes = javers.findChanges(QueryBuilder.byInstanceId("345", 
           RegexRegisteredService.class).build()); 
    System.out.println(changes.size()); 

Le résultat de l'extrait de code ci-dessus est 0.

Diagnostic

diagnostics D'autres montrent que les références d'objets dans les classes contenant obtenir leur propre identité la fonction findChanges() ne regarde que la classe/l'entité contenant cet ID et ne parcourt pas la hiérarchie pour localiser d'autres références et propriétés. Lorsque la InMemoryRepository commence à comparer les clichés de l'histoire à la globalId qui est passé, il suffit de regarder les parents globalId et ne baissera pas la liste des classes contenues:

Iterator it = this.getAll().iterator(); 

    while(it.hasNext()) { 
     CdoSnapshot snapshot = (CdoSnapshot) it.next(); 
     if (snapshot.getGlobalId().equals(globalId)) { 
      filtered.add(snapshot); 
     } 
    ... 

Ici, le globalId qui est passé est org.apereo.cas.services.RegexRegisteredService/345. Cependant, rien dans cette identification n'a changé; Ce qui a vraiment changé est mappé à org.apereo.cas.services.RegexRegisteredService/345#usernameAttributeProvider qui ne sera jamais récupéré car la vérification ci-dessus échoue à la condition d'égalité.

La hiérarchie est en tant que telle:

public interface RegisteredService {} 

public abstract class AbstractService implements RegisteredService { 
    // with setters and getters 
    private UsernameAttributeProviderInterface usernameAttributeProvider; 
} 

public class RegexRegisteredService extends AbstractService {} 

Alternative?

Que diriez-vous de quelque chose comme ceci à la place? Cette fonctionnalité est-elle absente dans Javers, ou ai-je manqué quelque chose? Vous vous demandez si je devrais peut-être concevoir mon propre cours de dépôt?

Answer 1

avère que je devais faire quelque chose de très simple:

final List<Change> changes = javers.findChanges(
      QueryBuilder.byInstanceId("345, RegexRegisteredService.class) 
        .withChildValueObjects() 
        .build()); 

Référence: https://javers.org/documentation/jql-examples/#child-value-objects-filter

Answer 2

Probablement, vous avez tracé les objets visés comme ValueObjects (valeur par défaut). Dans JaVers, ValueObjects sont traités comme des conteneurs de propriétés et leur type n'est pas important lorsqu'ils sont comparés. Cela se reflète dans le GlobalId:

org.apereo.cas.services.RegexRegisteredService/345#usernameAttributeProvider 

Si vous voulez suivre les changements de type, vous devez mapper les objets mentionnés comme entités