Handle bi-directional references using declarative method(s)

I think I know a reasonable way to indicate relationship:

• "Parent" reference must be annotated (@JsonParentRef or SourceRef); type can be POJO, Map, Collection (i.e. almost any type), value type must point to valid child type (one with annotation, see below). Serialized normally; only affects deserialization part.
• "Child" reference annotated as well (@JsonChildRef or TargetRef). Must point to POJO (not other structured type). Not serialized; special handling during deserialization

Limitation in usage is that relationship between the two must be possible only using declared type (in future, could maybe allow a discriminator too – for now, let's assume simple case).
If so, parent type deserializer can do post-processing step after instantiating children: it needs to inform child deserializer that parent reference is now available, to request assignment

This should allow re-creating back references fairly easily, reliably and efficiently. The only question is when there's time to do it.

I wonder could we consider using JSON Referencing as discussed in the JSON Schema proposal http://json-schema.org/

This link details how JSON objects with circular references could be represented http://www.sitepen.com/blog/2008/06/17/json-referencing-in-dojo/

Where could I find the @JsonParentRef annotation? I hava the same problem. The thread is in Spring forum: http://forum.springsource.org/showthread.php?t=85195&page=2
Thanks in advance!

james: question of using json schema is somewhat orthogonal to annotations – two are not conflicting. Schema is external specification that Jackson does not currently use, although it can produce basic schemas out of existing object definitions.

Personally I am bit disappointed at json schema work, since it solely focuses on describing json, having very little to no support for modularity, or challenge of OJM; inheritance and such.
Its value addition is quite modest compared to complexity, for data binding use cases.
Still, we can certainly support it to degree possible, once someone with strong enough itch wants to tackle challenge.
It could be part of solution, just not the whole solution.

Recoco: note that this issue has not been worked on, so annotations have not been added as of yet. They will be if and once work starts.

Can anyone suggest a work-a-round for this in the meantime?

Quick update: annotations added are @JsonManagerRefeference and @JsonBackReference. They are not yet handled, but code will use these.

First version now works (see unit tests .../map/deser/TestParentChildReferences); will need to add support for collection types as well.

Implemented, works for beans, arrays, lists and maps.

Any date as to when 1.6 is going to be released?

Hoping to get work done by end of July. The only thing I absolutely want to get in is "materialized interfaces", beyond that other parts are more or less optional.
I consider finalizing 1.6 a high priority (wrt "release early, release often").

Interesting... Is @JsonBackReference treated just like @JsonIgnore? Because I can't see any difference...

Hi, just a quick question: As far as I can see, the new annotations don't fully work (i.e. at deserialization the "back link" does not get populated) when the class of your @JsonBackReference is an abstract one ... are there plans to support this in the future? Thanks and greets!

Kyrill: just like @JsonIgnore for serialization, but not when deserializing: in latter case link is re-constructed from context.

Michael: correct, there is the bug JACKSON-368 and matching unit test: these two features unfortunately do not play nice, and I don't yet know how to fix the issue. It seems rather tricky one, unfortunately. But it is not forgotten.
So hope definitely is to support this, but it is not a simple bug to fix (unless I am overlooking something obvious). Make sure to vote for the bug if/when you have hit it, that makes it easier to find priorities for long(er) standing bugs.

It is mentioned in the above comment that JsonBackReference does not work for deserialisation and I can verify that this is the case. When doing a Parent-Child relation with JsonManagedReference and JsonBackReference, the parent on the child does not get set during deserialisation.
Shouldn't this issue be reopened or is this bug covered in JACKSON-368?

Deserialization works just fine for other types (as far as I know, as per tests), but the specific case of types that use polymorphic type information (@JsonTypeInfo) does not work.
That is, the problem is with combination of these two features; specifically that parent type handling must know field/method to use for both sides, for relinking, and this is not available at the point where it is currently done (since abstract type is resolved at a bit later step).

But if you do have issues for other cases (possibly found another bug), please file a new Jira bug (or ask on the mailing list) so we can see what is happening.
There are other things that could be causing issues; for example, many users get bitten by the fact that annotations are not shared between getters and setters; and so if annotations are only added on, say, getters (which are used for serialization) they will not currently affect deserialization unless setter also has it. This is not problem with fields, as same field is used for both operations.

It does seem to work both with field annotation and property annotation - however for property annotation you are required to annotate both get+set on both sides of the relation.
F.ex: in a Parent-Child relation where parent can have many children the following annotations are required if deserialization is to work:

 
public class Child {
    private String name;
    private Parent parent;
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    @JsonBackReference
    public Parent getParent() {
        return parent;
    }
    @JsonBackReference
    public void setParent(Parent parent) {
        this.parent = parent;
    }
}

public class Parent {
    private String name;
    private List<Child> children = new ArrayList<Child>();
    public void addChild(Child child) {
        if (!getChildren().contains(child)) {
            getChildren().add(child);
            if (child.getParent() != null) {
                child.getParent().getChildren().remove(child);
            }
            child.setParent(this);
        }
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    @JsonManagedReference
    public List<Child> getChildren() {
        return children;
    }
    @JsonManagedReference
    public void setChildren(List<Child> children) {
        this.children = children;
    }
}

If setChildren is either missing or not annotated child.getParent will be null when deserialized from JSON. Serialization works without it. Design-wise addChild could make setChildren obsolete, but for this to work it is required to be exposed.

Correct: setter/getter pairing is a known and long-standing sub-standard feature of annotation handling.
So solution to that particular problem has to be done for the whole annotation processing framework, and will require extensive changes to some internal (or semi-public, in case of AnnotationIntrospector) abstractions. This is the main reason this has not been changed yet.

So, this is not a problem specific to this feature, unfortunately.