tracker issue : CF-3712823

select a category, or use search below
(searches all categories and all time range)
Title:

Serialise queries to JSON better

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/NotABug

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 02/24/2014

Components: Language

Versions: 11.0

Failure Type: Data Loss

Found In Build/Fixed In Build: PublicBeta /

Priority/Frequency: Major / Most users will encounter

Locale/System: English / Platforms All

Vote Count: 0

See http://cfmlblog.adamcameron.me/2014/02/coldfusion-11-query-column-types.html and http://cfmlblog.adamcameron.me/2013/06/coldfusion-vs-json-how-to-make.html

You're claiming (https://wikidocs.adobe.com/wiki/display/coldfusionen/ColdFusion+Language+Enhancements#ColdFusionLanguageEnhancements-Datatypepreservation) "SerializeJSON considers datatypes defined in the database for serialization", but that is not true. You are not.

I suggest you alter the JSON schema you use for serialising queries to be along these lines:

{
    "COLUMNS":["ID","MI"],
    "COLUMNTYPES":["integer","nvarchar"],
    "DATA":[
        [18,"R?hina"],[19,"R?t?"],[20,"R?apa"],[21,"R?pare"],[22,"R?mere"],[23,"R?horoi"],[24,"R?tapu"]
    ]
}

Note the COLUMNTYPES. Then you actually WILL be doing something sensible with the data types.

But you currently are NOT doing anything sensible here, so you should stop claiming that you are.

-- 
Adam

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3712823

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

Adam, respectfully, I think you may misunderstand the change here. The change was meant to try to ensure that strings became strings in JSON and numbers stayed as numbers. It was not meant to impact the *structure* of the serialized query - that is another feature. Rather this change relates just to data type. Hit me on IM if you want to hash this out further, and if I have misread you, ignore.
Comment by External U.
13261 | February 24, 2014 08:54:09 PM GMT
SerializeJSON definitely considers the datatype defined in the DB for serialization. As Ray pointed out, with this change, string remains string and numbers remain number and so on when a query is serialized in JSON. If you have any example which shows that it is not happening, please share it with us.
Comment by Rupesh K.
13262 | November 13, 2014 03:09:51 AM GMT
No, it's fine as-is for the scope of this ticket. As Ray says, what I'm suggesting - whilst being a good suggestion - is a different issue.
Comment by External U.
13263 | November 18, 2014 10:32:30 AM GMT
How do I flag this back as "there, you have the info you were waiting on"?
Comment by External U.
13264 | November 18, 2014 10:33:01 AM GMT
Adam, looking at your entry, I may have misread it,and if so, I'm sorry. It sounds like you want to add a new set of data, columntypes, so that the client code can know what it was, is that so? I have a comment on that but want to confirm first. And again - I apologize.
Comment by External U.
13265 | November 18, 2014 11:22:26 AM GMT
Indeed. There are two issues here: 1) the thing that Adobe have done: use DB metadata to correctly work out that a varchar column with numeric value is still a string when serialising, etc. 2) extending Adobe's query serialisation so that the datatyping is preserved for when deserialising it. It was the latter I was expecting to see, but I get this is not what Adobe set out to do, and what they *have* set out to do is working. Even if it lacks ambition and thoroughness (IMO).
Comment by External U.
13266 | November 18, 2014 11:35:25 AM GMT
Fair enough. The comment I was going to make was this: I don't think the metadata for queries will *often* be useful for a client side dev, assuming things are serialized ok. But I could see including it being a useful option. I'd be in favor of this being added if was an option. (If that makes sense.)
Comment by External U.
13267 | November 18, 2014 11:38:29 AM GMT
Yeah, but JSON's used for a lot more than client-side interchange these days.
Comment by External U.
13268 | November 18, 2014 12:10:08 PM GMT
I concur - I just don't know often you would need the datatype. If we assume data is serialized correctly, I think it is rare that you would want to know that column X is string and Y is int. It is just part of the API documentation. I *do* see a possibility where the data itself is dynamic. For example, you are returning any number of _different_ things, and then this type of info would be useful. I'd make it optional though since if you don't need it, you shouldn't return it (since it makes the data size bigger, even if a tiny bit).
Comment by External U.
13269 | November 18, 2014 12:12:48 PM GMT
Thanks Adam and Ray. We will close this bug then. As far as including the datatype in JSON is concerned, I don't see many use-cases for it since the datatype is very specific to database. But if you think that it will be very helpful, please log a separate E/R for that.
Comment by Rupesh K.
13270 | November 19, 2014 01:10:01 AM GMT