I'm no where near the level of an overlord, except maybe to the wifes dog. I'm in a debate mood, so why not? I'm open to the firing squad today. :]
IMHO, there are four (I initially started with two) problems with this request in making it part of the core dealings Dr Hipp provides us all. I say this without knowing what the OPs purposes are to have SQLite start understanding what JSON is and how it is handled. Information Exchange Technologies (IET) shouldn't be part of a database language. STORED in a Database, sure, of course, no problem. Technologies like XML, JSON, HTML, BMP, JPG, MP3, TXT, DOC, XLS, and anything else that contains information that is presented AS A WHOLE to a client/recipient is part of the IET group. SQLite isn't part of that group. SQLite is a *organizational *and (hopefully) *organized *storage medium. You put data in, it stores that data. All of it. In one container. It doesn't matter what that data is, it just stores it and knows how to get it when needed. With IETs, all data is exchanged, not just select parts of it. With a DBMS, changing one or two pages in in a terrabyte sized data doesn't cause a terrabyte worth of data to be rewritten when you change a 1 to a 0 or an Z to an F, unlike any IET. I'll cede to that you can open up a hex editor and single byte/char write to change that 1 to a 0, but, change that 1 to a the content of this email thread in an XML file without writing out the whole file again. DBMS shouldn't ever deal with an outside technology other than a Structured Query Language which boils down to a table containing rows and fields. It shouldn't ever need to think about what is in a 'cell' in a table and how to handle it. The outside world says "I want this information, gimme" and the DBMS should get it. The DBMS should only ever play within its own sandbox, and not allow the other kids to play with it. JSON specifically is for client use, configuration use, or rarely changing data in kilobyte chunks of information at most. If you're going to start throwing the overhead of interpreting what JSON is within the DBMS, you might as well just use the DBMS language for better storage and retrieval of information, then have your n-tier application handle the "manglement" of the JSON for whatever you need. Since JSON is setup as a key:value standard (Value being number, string, or array of sorts), you could stretch this into the thought that this is a valid structure to a database. After all, you have a field:value relationship with SQL. However, storing a database within a database seems to be quite a bit redundant to me. XML and JSON should rendered upon output from a database query, and any JSON/XML that is to be put into a database should be dissecting the data outside the database engine with appropriate tables. The exception to this might be for static configuration files based on a users preference, system configuration, etc. But changing data? I'm seriously iffy. It'll eventually get to the point where you'll get into 'database'ception and that is a whole other puddle of mud. Theory would be to make a database to take the stored database to make the change then re-store the database in a cell of a database. Lastly, part of SQLites title says it all. Lite. If every technology were added to handle information exchange, might as well start calling it SQLarge. SQL-Bloat or SQL-Fat just don't have the same ring to it, eh? If JSON gets in, who's to say XML doesn't go in? Or HTML as a query? Or if someone figures out how to convert a PNG to a database structure, why not throw that in? My point here is that IET changes all the time, and it isn't the responsibility of a database engine to keep up which has its own kids to feed. Now, with those four points, that doesn't exclude that the possibility exists to add such functionality. If you use the amalgamation, and you know C, you can always add the additional functionality on your own. IIRC, there are methods to include calls to external modules/DLLs/whatever that you'll have to write on your own, so you may not have to be entirely reliant on C. I've not checked, but there may already be modules that 'plug in' to the SQLite DLL that'll do exactly that JSON interpretation. Myself, if you've not figured out, I feel that a database should store raw information. BMP grade level of storage. Raw, unaltered, factual, bottom line information. Anything that could be considered an interpreted piece of information, such understanding what a PNG is versus a BMP shouldn't be part of the DBMS. It doesn't matter how convinient it may be to have the DBMS understand the difference, the purpose of a DBMS isn't to know, but just acknowledge that something is there (Or not there in the case of NULL) On Tue, Apr 21, 2015 at 9:09 PM, Ashish Sharma <ashishonline at gmail.com> wrote: > Hi > > Many times I store JSON data in sqlite. It will be useful if sqlite came > with functions which understand JSON. Presto has a nice set > https://prestodb.io/docs/current/functions/json.html > > I have two questions > > 1. Will sqlite overlords consider adding this to sqlite core? > 2. If so, what steps are needed for this? > > Thanks > Ashish > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
