Change processing

I am trying to figure out how the library would be used to show a traditional “changelog”. By traditional I am referring to something that is grouped together by “commit” then by field.

        List<Change> changes = javers.getChangeHistory(InstanceIdDTO.instanceId(table.getInternalId(), Entity.class), 5);

        for (Change change : changes) {
            CommitMetadata commit = change.getCommitMetadata().get();
            System.out.print(commit.getId() + ":" + commit.getCommitDate() + ":" + commit.getAuthor() + " -- ");

            // What type of change is it?

            // I could say "if (change instanceof ValueChange)" and check for every type
        }

So a couple of questions:

1. The documentation is missing in some places, so I may have missed it. Is there a way to get “commits” instead of “changes”? Commits would store the CommitMetaData and have a list of Changes? Otherwise, I would just build it myself, which is not too difficult.
2. When I am looping over the changes, how do I know what type of change it is? I.E NewObject, ValueChange, MapChange, etc. In all the examples I saw, you were retrieving changes by type. However I would like to build a complete changelog so I don’t know beforehand which types to ask for. I could do a bunch of casting based on instanceof but that doesn’t see right. Is there a more elegant way, given a Change, to determine its actual type?

[ctmay4]

I totally agree about casting. Should be avoided at all costs. So let’s say I have an entity and I want to build a complete change history to display to the user. In the method you suggested above, I would need to call getChangeHistory a bunch of times, one for each class derived from Change. I would have to look over each set of results and join everything together based on Commit so that I would show it in the order it all happened. It seems like there should be an easier way that would not force me to understand every class that is derived from Change.

One way would be to have the toString method in the Change class be used. Classes like NewObject, PropertyChange, etc. would override it with a relevant description of what actually happened. That would be an improvement and probably makes sense to do. However it would not allow me to customize the message, so I’m not sure if I would call it a complete solution.

Ideally, I could do everything I need from the Change object without knowing the concrete implementation I was working with. A “change” consists of 1 of 3 things:

• The object was created
• A property value on the object changed
• The object was deleted

I am not sure, but it seems like I should be able to get from the Change object somehow:

1. Type of change (ADD, DELETE, MOD)
2. Property name changed (only for MOD)
3. Old value (only for MOD)
4. New value (only for MOD)

That would break your current hierarchy, so I’m not sure it is something that would work. However this use case of building a complete history of an entity seems like it should be one of the basic requirements of the library.

[bartoszwalacik]

Answering your questions

• There is no such feature yet. Commits can be assembled from Changes & Snapshots so it’s doable. If you think it could be useful , please create specific issue with api proposal. How this new JaVers method could look like?
• In fact, instanceof and casting is not very cool. I could create method like Chenge.getType(), that returns String or Enum but I doubt it helps. I think, better way is filtering.

We can add method like that:

public <C extends Change> List<C> getChangeHistory(GlobalIdDTO globalId, int limit, Class<C> ofType)

So no casting would be required, what do You think?