Serializing string fields with json data

[csantero]

I haven't come across a way to send and receive dynamically-typed data. For example, I have some tables in my database with columns that store JSON data. When serializing one of these columns, I don't want to send the value as a string, but rather as an embedded JSON object.

I'm thinking maybe we invent an attribute like [SerializeAsRawJson]. If it is present on a string property, the formatter will embed it as a raw JSON object instead of as a string.

[SphtKr]

This is easily doable, technically...at least for serialization...we might hit a snag or two supporting that for deserialization, but we also might not. Two questions:

1. There's already a SerializeAsAttribute that takes an enum parameter specifying a serialization method. Right now, it only applies to relationship attributes. Probably the quickest way to do this would be to just add another enum value that denotes "raw JSON" and let the attribute apply to relationships and "value" properties. In fact, there's already an enum value for "Embedded", and we could make that apply to relationships and value properties, with the value property behavior being what you describe (that setting is not yet fully implemented for relationships though!). If we don't go that way, and keep SerializeAsAttribute applicable only to relationships, does it need renaming?
2. This is technically outside the spec, right? Or is there a section on complex non-relationship (i.e. not appearing in linked) values that I'm missing? If the latter I'd be interested, because that'd apply to Ember Data's embedded relationship feature also. Do we need to isolate or flag this feature somehow as being non-compliant? Or would this just be considered "in addition to" the spec?

FWIW, I do something similar, but I just leave it as a string and have a DS.Transform on the Ember Data side to "hydrate" the string. Not opposed to implementing though, because this is essentially a 2nd mechanism for allowing the "Embedded" objects supported by Ember Data.

[csantero]

1. I don't like reusing SerializeAsAttribute here because all the other enum values besides Embedded are meaningless in this context.
2. Yeah the spec doesn't really have much to say about this, it's definitely extra. I don't think it's necessary to flag it or anything, though, because it doesn't interfere with the spec.

As for Ember Data, when I had this working with my old json-api library, I was using a custom "Raw" transform. Serializing raw json is going to be more user-friendly than requiring string hydration, so I vote for this approach.

I'll throw up a PR today.

[SphtKr]

Okay, cool. Would it make sense to parameterize your attribute for any other use cases? I'm thinking maybe #29, one could pick string or number serialization for Decimal? And then should we rename the current SerializeAs to SerializeRelationshipAs perhaps?

[csantero]

I know it proilferates our attributes a bit, but I was kind of thinking of having a separate one for each type. So:

• [SerializeStringAsRawJson]
• [SerializeDecimalAsString]
• [SerializeDecimalAsNumber]

It's a little weird, but it makes it clear what types each attribute should be applied to, right there in the name. Ideally Visual Studio would let you restrict attributes to properties of a given type, but that's not possible.

The alternative, something like:

• [SerializeValueAs(SerializeValueSettings.Raw)]
• [SerializeValueAs(SerializeValueSettings.String)]
• [SerializeValueAs(SerializeValueSettings.Number)]

makes the attribute seem more flexible than it is.

And then should we rename the current SerializeAs to SerializeRelationshipAs perhaps?

That's a good idea but I think I'll put that in a separate PR.