Are you seriously saying that that SQL syntax is friendly? How can you
defend SQL syntax other than on grounds of history or standardization? If
you're more comfortable and familiar with JSON the yes it is easier and you
can avoid an unnecessary conversion step.

If you're using JavaScript you'd send JS objects (ie binary equivalent of
JSON) to the parser rather than SQL since it's frictionless and binary to
binary. Doing that is safer and more efficient, not to mention the savings
in programming and bugs from the SQL generation, which is the biggest win
of all.

On Thu, Jun 4, 2015 at 2:26 PM, Richard Hipp <drh at sqlite.org> wrote:

> On 6/4/15, Darko Volaric <lists at darko.org> wrote:
> > My point about JSON, etc is that there is no reason not to use that as a
> > query language if that makes it easier. If your system is efficient with
> > JSON, why not accept a query that is formatted as JSON? It's not
> > semantically different to SQL syntax. Here's an example (with a roughly
> > JSON notation):
> >
> > {
> >   operation: "insert"
> >   table: "blah"
> >   columns: ["a", "b", "c"]
> >   values: [1.3, 2.0, 3.1]
> >   on-conflict: "replace"
> > }
> >
> > That is equivalent to an INSERT SQL statement, but why form that SQL
> > string, possibly using memory and time, when your system can spit out
> JSON
> > (or whatever) effortlessly?
>
> What is the JSON equivalent to the query shown below?  Can you
> honestly say that the JSON equivalent (whatever it looks like) is
> somehow easier to generate, read, parse, and/or debug than the SQL?
>
> SELECT
>   sp.name, st.bug_name,
>   (SELECT cve_desc FROM nvd_data WHERE cve_name = st.bug_name),
>   (SELECT debian_cve.bug FROM debian_cve
>     WHERE debian_cve.bug_name = st.bug_name
>     ORDER BY debian_cve.bug),
>   sp.release,
>   sp.subrelease,
>   sp.version,
>   (SELECT pn.fixed_version FROM package_notes AS pn
>     WHERE pn.bug_name = st.bug_name
>       AND pn.package = sp.name
>       AND(pn.release = sp.release OR (pn.release = '' AND
> fixed_version != ''))),
>   st.vulnerable,
>   st.urgency,
>   (SELECT range_remote FROM nvd_data WHERE cve_name = st.bug_name),
>   (SELECT comment FROM package_notes_nodsa AS nd
>     WHERE nd.package = sp.name AND nd.release = sp.release
>       AND nd.bug_name = st.bug_name) AS nodsa
> FROM
>    source_package_status AS st,
>    source_packages AS sp, bugs
> WHERE
>    sp.rowid = st.package
>    AND st.bug_name = bugs.name
>    AND ( st.bug_name LIKE 'CVE-%' OR st.bug_name LIKE 'TEMP-%' )
>    AND ( sp.release = 'sid' OR sp.release = 'stretch' OR sp.release =
> 'jessie'
>           OR sp.release = 'wheezy' OR sp.release = 'squeeze' )
> ORDER BY sp.name, st.bug_name, sp.release, sp.subrelease;
>
> --
> D. Richard Hipp
> drh at sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

Reply via email to