5 ms·
Please stop using json as a data model. I have no idea how to represent dates, or timestamps, or colors, or any other unsupported data type.
by perfunctory 14y ago
Please stop using json as a data model. I have no idea how to represent dates, or timestamps, or colors, or any other unsupported data type.
- crazygringo 14y agoI have nothing to do with RethinkDB, but what are you talking about? Just represent them as strings. (What databases support colors as native types, anyways?) If you format dates YYYY-MM-DD, then you can do string comparisons for ranges. And JSON has the huge advantage of supporting hierarchical data -- arrays with objects inside, etc. It seems a like a huge step forward.
- kemiller 14y agoBut there's no standard way of representing the dates as strings, or indicating that this field here is a date and not a string that happens to look like one, so nothing can rely on what you do. You can represent literally anything with a string, but you lose type information when you do.
- cpeterso 14y agoISO 8601 is a standard way of representing dates as strings, e.g. "2012-11-09T08:08Z".
- inportb 14y agoHopefully, your application knows that this field here is a date encoded in a string.
- rdtsc 14y agoThere is a standard for representing string (see sibling comment) and your type information is the field name. So you know your document has a type if you give it a d_type field for example and then based on that you know your tstamp field is the date.
- kemiller 14y agoI'm not saying I can't imagine how to work around it, I'm saying that we're forced to, and likely will do so in a variety of competing ways, which degrades its usefulness as an interchange format. It means your tools, at the end points or in the middle, don't know what the data in that field is and so can't do anything useful for you that you haven't explicitly taught it to do.
- lttlrck 14y agoOr unix epoch if you want an easy life when it comes to querying.
- optymizer 14y agoSo because you have no idea how to represent some arbitrary things with JSON, we should all stop using it? You, sir, are not making any sense. Also, you seem to be confusing primitive data types with complex data types. Yes, JSON doesn't have a 'color' data type. But guess what? Neither does C, nor Java. If you want a 'color' type, you'll have to create one yourself! Mind blowing, I know. So here, let me suggest a possible solution: dates: string timestamp: integer colors: string (RGB,BGR,RGBA,...), integer, object Part of 'data modeling' is to model your data out of basic types. Shocking! If JSON had types for every type of object under the Sun (like you seem to want), JSON parsers would be a lot more complicated and little thinking would be required in the process of modeling your data.
- optymizer 14y agoSo because you have no idea how to represent some arbitrary things with JSON, we should all stop using it? You, sir, are not making any sense. Also, you seem to be confusing primitive data types with complex data types. Yes, JSON doesn't have a 'color' data type. But guess what? Neither does C, nor Java. If you want a 'color' type, you'll have to create one yourself! Mind blowing, I know. So here, let me suggest a possible solution: dates: string timestamp: integer colors: string (RGB,BGR,RGBA,...), integer, object Part of 'data modeling' is to model your data out of basic types. Shocking! If JSON had types for every type of object under the Sun (like you seem to want), JSON parsers would be a lot more complicated and little thinking would be required in the process of modeling your data.
- perfunctory 14y agojson definitely has certain advantages. e.g. arbitrarily nested data structures. However. json is not extensible by design. There is NO standard way to define new custom data types in json.