Earlier quoted context omitted.
If the order of items in the JSON blob matters then JSONB probably wouldn't preserve the order.
JSON is unordered. Nothing in your code should assume otherwise. "An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array."
JSONB has landed
121–130 of 210 posts
Re: JSONB has landed
#122Earlier quoted context omitted.
I don't know if it's true of SQLite, but you missed the most important point at least with PostgreSQL : you can build indexes directly against attributes inside JSONB which really turns it into a true NoSQL / relational hybrid that can let you have your cake and eat it too for some design problems that don't fit neatly into either pure relational or pure NoSQL approaches.
What would that SQL look like in practice ?
If i just need the messages between certain temperatures i can speed this up by adding an index on the 'temperature' field in json.
create or replace view bme680_v(ts, message, temperature, humidity, pressure, gas, iaq) as
SELECT mqtt_raw.created_at AS ts
, mqtt_raw.message
, (mqtt_raw.message::jsonb ->> 'temperature'::text)::numeric AS temperature
, (mqtt_raw.message::jsonb ->> 'humidity'::text)::numeric AS humidity
, (mqtt_raw.message::jsonb ->> 'pressure'::text)::numeric AS pressure
, (mqtt_raw.message::jsonb ->> 'gas_resistance'::text)::numeric AS gas
, (mqtt_raw.message::jsonb ->> 'IAQ'::text)::numeric AS iaq
FROM mqtt_raw
WHERE mqtt_raw.topic::text = 'pi/bme680'::text
ORDER BY mqtt_raw.created_at DESC;Re: JSONB has landed
#123Lots of confusion on what JSONB is. To your application, using JSONB looks very similar to the JSON datatype. You still read and write JSON strings—Your application will never see the raw JSONB content. The same SQL functions are available, with a different prefix (jsonb_). Very little changes from the application's view. The difference is that the JSON datatype is stored to disk as JSON, whereas the JSONB is stored…
> If you're just using SQLite to write and read full JSON blobs, the JSON datatype will be the best pick. There is no json data type ! If you are just storing json blobs, then the BLOB or TEXT data types will be the best picks.
Why not? I feel like a database should allow for a JSON data type that stores only valid JSON or throws an exception. It would also be nice to be able to access subfields of the JSON.
SELECT userid, username, some_json_field["some_subfield"][0] FROM users where ...
Not sure where to give feature suggestions so I'm just leaving this here for future devs to find
Re: JSONB has landed
#124Earlier quoted context omitted.
JSON is unordered. Nothing in your code should assume otherwise. "An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array."
Assume you're writing an editor for JSON files. Don't think many users of that editor would be very happy if you change the order of the attributes in their json files, even though technically it's the same...
Re: JSONB has landed
#125What are the use cases for storing and manipulating json at the db level like this - why not use a relational schema and query it in the normal way?
Re: JSONB has landed
#126Earlier quoted context omitted.
Yeah migrations are the biggest issue for me. I really don't like not knowing what the actual shape of the document will be. Missing transactions, and not great relationship performance makes modelling some systems more hassle than it's worth. I gave it a good go to use mongo and firestore for a few projects, but after a year or two of experimenting I'll be sticking to SQL based DBs unless there are super clear and o…
There's a gradual approach there, where you start out with a JSONB column, and then as each piece of the data structure stabilizes* you move it out of json fields and into its own columns/tables. * meaning, when there's enough code that depends on it that changing it would require some planning
Re: JSONB has landed
#127Earlier quoted context omitted.
> If you're just using SQLite to write and read full JSON blobs, the JSON datatype will be the best pick. There is no json data type ! If you are just storing json blobs, then the BLOB or TEXT data types will be the best picks.
> There is no json data type Why not? I feel like a database should allow for a JSON data type that stores only valid JSON or throws an exception. It would also be nice to be able to access subfields of the JSON. SELECT userid, username, some_json_field["some_subfield"][0] FROM users where ... Not sure where to give feature suggestions so I'm just leaving this here for future devs to find
Re: JSONB has landed
#128Earlier quoted context omitted.
JSON is unordered. Nothing in your code should assume otherwise. "An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array."
Assume you're writing an editor for JSON files. Don't think many users of that editor would be very happy if you change the order of the attributes in their json files, even though technically it's the same...
Re: JSONB has landed
#129Re: JSONB has landed
#130Earlier quoted context omitted.
There's a gradual approach there, where you start out with a JSONB column, and then as each piece of the data structure stabilizes* you move it out of json fields and into its own columns/tables. * meaning, when there's enough code that depends on it that changing it would require some planning
Alternatively, keep it in the JSON/JSONB column until you need to search/filter/query on it, in which case you pull it out into a column.
Though most of the time, in that situation, I would pull it out.