Jackson-databind: @JsonIdentityInfo - Always Serialize IDs as Fields

[pgelinas]

@JsonIdentityInfo isn't meant to do that: it's meant to resolve cyclic dependencies in an object graph (during serialization and deserialization) by using an ID/reference mechanism so that an object instance is only completely serialized once and referenced by its ID elsewhere. So your first point ("making incomplete JSON objects") is an intended behaviour.

It is not a mechanism to add an ID field to an object JSON representation. There's no such feature in Jackson at the moment, so definitely you need a custom serializer to do that.

[ecavinat]

I understand what @JsonIdentityInfo's means, but I need a way of customize the ID's references to JSON resolution: the default behavior solves the problem partially and with @JsonIdentityReference(alwaysAsId = true) not solves at all...
There is a way to resolve these references before sending the generated JSON to browser (like replace a node someField : 1 by someField : { id : 1 }), searching and replacing that references?
Beside this, I downloaded project's source code and I will do some modifications to allow that behavior...

Thanks.

[cowtowncoder]

@ecavinat Jackson processing is all streaming, incremental there is no point during processing where there would be JSON to modify. If you do need such a representation, you can use ObjectMapper.valueToTree(), and modify this structure, before writing out.

But I don't think the original description quite explain what exactly you are trying to do: could you explain it with an example? At least I could not fully understand the goal you have: you explained not what kinds of mechanism you want, but not what the result should be (and possibly also why) -- it is more important for us to understand what is the desired output (and why); and then it is possible to think of possible ways to make that happen.

[redben]

FWIW, here is an attempt by (stickfigure)[https://github.com/stickfigure] to do something like what you need, serialization is ok but not deserialization. https://github.com/jsog/jsog-jackson

[reda-alaoui]

Hi,

I am stuck with the same issue.
I am not sure I understood the issue resolution.

I want to use IntSequenceGenerator with a generated property named @id.
Sometimes we obtain the following:

{
   "a": {
     "@id": 1
   }
}

other times the following:

{
   "a": 1
}

We need to always retrieve the object with the first representation.

Is that possible?

[redben]

@reda-alaoui have a look at https://github.com/jsog/jsog-jackson

[reda-alaoui]

Ok great, thank you

[cen1]

I am not entirely sure why this issue is closed since there is no solution to the question (using yet another external library is not ok). The requested feature seems rather simple to me (not knowing the internal workins of Jackson):

We need to get from this:

"store": "f8aca5e4-c09f-4bf8-81e5-f6f0fad251a5"

to this:

"store": {
  "id":"f8aca5e4-c09f-4bf8-81e5-f6f0fad251a5"
}

This way we keep the JSON model consistent and "store" does not suddenly transform into a string when it should be an object. Is anything being worked in this direction or could we re-open this as a feature request?

[cowtowncoder]

@cen1 Jackson will serialize Object Ids as simple scalars, and not as Objects. This is the design choice, and htis is why this is closed. References are NOT OBJECTS, so why would you embed them in unnecessary wrapping? Or, if you want such complicated reference objects, feel free to implement them using whatever means you want. It is difficult enough to get all the other features working -- specifically, unwrapped properties and polymorphic handling -- and due to lack of separate metadata, or even good conventions, in JSON, I do not think there is a way to reliably use JSON Object wrapping for yet another thing.

Still, I am always open to PRs that suggest alternate way of doing things. I have just zero interest in pursuing this approach myself -- I think it is fragile, complicated way to go, and will not lead to robust and well-functioning system.

[sotty]

I also think it is a bit of an issue, mostly for compatibility with other tools that (de)serialize references using the { "@id" : "URI" } pattern.
For example, I am trying to serialize certain annotated classes into JSON-LD, then read them using Jena or OWL-API (in and out of Protege) to implement a 'semantic data model'. With IDs being treated as strings, not only I get a broken graph, but reasoners also complain about an inconsistency: OWLObjectProperties cannot have xsd:string for range