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

Circular references #133

Open
pschleger opened this issue Oct 4, 2016 · 3 comments
Open

Circular references #133

pschleger opened this issue Oct 4, 2016 · 3 comments

Comments

@pschleger
Copy link

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.

@jodastephen
Copy link
Member

Wondering exactly what you have in mind in pseudo code. This only affects mutable beans (immutable ones cannot have circular references).

@pschleger
Copy link
Author

pschleger commented Oct 5, 2016

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 @PropertyDefinition(equalsHashCodeStyle = "omit", toStringStyle = "omit") to get around the problem with hashCode and toString, but JodaBeansSer will fail with StackOverflowError.

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:
url

@jodastephen
Copy link
Member

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 BeanBuilder hides this).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants