-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
Circular references #133
Comments
Wondering exactly what you have in mind in pseudo code. This only affects mutable beans (immutable ones cannot have circular references). |
Hi, taking an (contrived) example from capital markets, suppose you have a model whereby a trade has a product field, which is an interface implemented by specific products, such as a swap. Now suppose that the (legacy) model specifies that the cashflows are attached at the product level, and the cashflow has a reference to the parent trade to which the cashflow belongs. One could annotate the parent field with It would make sense to use ImmutableBeans and drop the circular reference in this example, but there can be technical reasons for needing the mutability (i.e. legacy hurts). I guess the pain I see at the moment is in regards to using JodaBeans for serialization. Jackson and Xstream to handle circular refs. Here's an illustration: |
So, I think the main difficulty here is how to link the child back to the parent object. I don't really want to go down the route of assigning identifiers to each object, or specifying a property as the "primary key". The only way I think it could work is to refer to the parent object by distance up the stack. However, deserializing would be tricky as the parent object would not necessarily be created at the point that it needs to be added to the child (the |
Any chance of getting support for circular references? They will ruin toString, hashCode and JodaBeanSer serializations.
Circular references do crop up, especially when onboarding legacy data models and converting these to Joda-Beans. Rather than redesigning the model, it would be really nice if provisions were made to handle them.
The text was updated successfully, but these errors were encountered: