Skipping One Side of Bidrectional Links / Collection Handling

[ghost]

From [email protected] on March 30, 2010 09:35:59

I intend to use YamlBeans to automate data provisioning for integration
tests. The objects to be (de-)serialized are normally retrieved from a
database and often have bidirectional links:

Parent:

• Collection children
• void addToChildren(child)

Child:

• Parent parent

Since fixing the serialization of cyclic references this structure can be
serialized however it is heavily anchored without any real need.

Secondly, current deserialization code assumes that collections can be just
created, added to and assigned to the object being deserialized. In my case
collections are normally read-only and can be only worked on using specific
addTo_, removeFrom_ methods (also making it easier to track changes).

The attached patch does two things:

• Introduce a writeConfig parameter to skip immediate collection
  backreferences
• Introduce pluggable handlers for collection deserialization
  (CollectionDeserializer)

It also includes new unit tests for the mentioned use cases...

Attachment: backreferences-collections.patch

Original issue: http://code.google.com/p/yamlbeans/issues/detail?id=2

[ghost]

From [email protected] on April 01, 2010 05:46:38

I forgot to include two files in the patch. Additionally skipping of back references
did not work if default values were always written.

Attachment: backreferences-collections.patch

[ghost]

From [email protected] on April 12, 2010 19:15:58

Thanks for the patch!

I see the need to use methods to manipulate a collection, thanks!

The "skip collection backreferences" setting skips the references in the list of the
object whose property the list will be assigned to? This seems like a pretty strange
thing to do. Is there any reason someone else would want to do this?

Status: Accepted
Owner: nathan.sweet

[ghost]

From [email protected] on May 14, 2010 00:58:29

The skipping if meant to be used for bidirectional links which are really common if
you use any type of ORM like Hibernate. The "backreference" is normally the owner of
the current object and the current object is contained a a list of the owner.

Example: You have an object Invoice that has a List. Every LineItem
references its owning Invoice. In Practise the methods to set the Invoice on a
LineItem and the method to add a new LineItem to an Invoice are written such that the
other side of the reference gets updated automatically.

When serializing without reducing the backreferences you get an aweful lot of anchors
which clutter the whole yaml file. On top it makes it less likely to be able to copy
and paste the serialized version to another file because auf conflicting anchors.

Invoice &1:

• LineItem:
  invoice: *1
  amount: 1.22
• LineItem:
  invoice: *1
  amount: 2.34

when skipping it becomes

Invoice:

• LineItem:
  amount: 1.22
• LineItem:
  amount: 2.34

which can be deserialized to the same object graph.

I agree that it tis a special case and being a general purpose library you should
maybe instead think about adding filtering support, such that you can exclude certain
property names on concrete instances

[ghost]

From [email protected] on May 14, 2010 01:01:15

Just as a addendum: I meant property names broadly, as in private fields or JavaBean
properties.