JSON type without encoding/decoding

[Tobion]

The JSON datatype (see #2653) automatically encodes/decodes the JSON datastructure. We need a JSON datatype that does not do this for several reasons:

• It's easier to switch existing text columns to json as we can keep using strings
• Sometimes you get JSON and just want to save it. It doesn't make sense to decode it, just so that doctrine can encode it again when inserting.
• More flexibility by being able to use any different serializations, e.g. using JMS serializer or json_decode($data, false) instead of json_decode($data, true) which is hard-coded into the JSON type.

So I'd propose to rename the new json type to json_decoded and introduce a new json type that uses a plain json string internally without transformation.
I chose json_decoded because you effectively work with a decoded json structure all the time (similar to old json_array). json_decoded would be more correct because it does not need to be an array. It can also be null or a string or int etc. decoded from json.

[Tobion]

An alternative name for json_decoded would be json_data

[jvasseur]

I would prefer to keep the current type named json. Maybe a non-decoded type could be named json_string.

[Ocramius]

Agree: json for the introduced type, json_string if you really need a string (and tbh, I don't see why json_string would be in core) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

…

On Fri, May 12, 2017 at 6:09 PM, Jérôme ***@***.***> wrote: I would prefer to keep the current type name json. Maybe a non-decoded type could be name json_string. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2723 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakI6D6HGJ449bkVYgVE_VIAP7vInqks5r5IQcgaJpZM4NZayw> .

[Tobion]

json_string as name does not make sense to me because it's not clear if it's a decoded string from json or a raw json string. json_array was also a decoded array.

I don't see why json_string would be in core

I gave three reasons above. Also DBAL is just an abstraction over DB access. So it's more logical to have a plain JSON type than a magic JSON column that decodes and encodes magically. Otherwise you could add alot more types with different serialization forms to the core.

[jvasseur]

json_string seems logical to me, it's a string containing json. But I agree with @Ocramius not sure if it should be in core.

I'm against renaming the current json type for a few reasons:

• it feels like the most common use case is to want the decoded json data rather than a non-decoded json string (to store free form data).
• the PR introducing the type was merge nearly 2 year ago, there is probably some project already using it (even if it never was in a released version).
• some package exists that introduce similar types with the name json (one of them is https://github.com/sonata-project/sonata-doctrine-extensions)
• it is designed as a replacement for json_array except it isn't made only for storing arrays so json seems logical.
• doctrine types always return the decoded data (ie: date types return DateTimeInterface instances instead of the date string).

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.