Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property name change casues JaversException, we need 'alias feature' to register old names #178

TimSin opened this issue Jul 7, 2015 · 5 comments


Copy link

@TimSin TimSin commented Jul 7, 2015

In the process of developing an application I have had to change a property name in one of my classes. This now leads to an exception being thrown when I try to commit a snapshot of the object to Javers:

JaversException: PROPERTY_NOT_FOUND JaVers runtime error - property 'name' not found in class 'org.xxxx.ips.model.Course'

Clearing the mongo db of all data associated with the object clears the issue, but obviously this will be problematic with a live system. Is there a way that Javers can deal with property name changes to underlying objects without loosing all historical audit data associated with them?

@pszymczyk pszymczyk self-assigned this Jul 7, 2015
Copy link

@pszymczyk pszymczyk commented Jul 8, 2015


Currently Javers doesn't support property name changes, but I think it could be very nice feature if you have some ideas how to deal with it we could discuss it and prepare some solution :), for now you can execute some script updating Javers sctructures or change your class name and store changes from the beggining.

@pszymczyk pszymczyk added the question label Jul 8, 2015
Copy link

@bartoszwalacik bartoszwalacik commented Jul 8, 2015

We could introduce aliases for properties and also for class names, configured in JaversBuilder

Copy link

@TimSin TimSin commented Jul 9, 2015

From an audit point of view, as long as the old property data was available in historical snapshots I would be happy. I guess that may make diffs more difficult, though to me it would seem logical to treat the now missing data as null and maybe store a Change to record when it was noticed that the old property was no longer present.

I haven't browsed the source extensively so I'm not too familiar with Javers internals, but looking at the ManagedClass source, I wonder if there is a way to make it aware of class versions? I was thinking along the lines of storing a Map of per-class property names keyed by Serial Version ID somewhere, with the data persisted somewhere in the schema? The obvious downside to this is that versioned classes using this feature would have to be Serializable.

The property alias idea sounds like a good feature, though would it cope with property deletion as well as re-naming?

Copy link

@bartoszwalacik bartoszwalacik commented Jul 9, 2015

Aliases could be use to handle renames. For example if you rename 'name' to 'forename' , you will add an alias 'name' to property 'forename'. Not sure about this class versioning idea. I think you can have only one class version loaded at a time.

@bartoszwalacik bartoszwalacik changed the title Property change casues JaversException: PROPERTY_NOT_FOUND Property name change casues JaversException, we need 'alias feature' to register old names Jul 18, 2015
@bartoszwalacik bartoszwalacik added enhancement and removed question labels Jul 18, 2015
bartoszwalacik added a commit that referenced this issue Oct 19, 2015
minor refactoring
bartoszwalacik added a commit that referenced this issue Oct 19, 2015
minor refactoring, makings things package-private
Copy link

@bartoszwalacik bartoszwalacik commented Dec 10, 2015

good news, JaVers 1.4.0-RC1 is ready, it gives you @TypeName annotation
and support for domain classes refactoring.
Check it out and give me feedback, does it solve your issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.