[sqlite] Backslash problems with json() and json_valid()

[Øyvind A . Holm]

It seems as json() and json_valid() misbehave about unescaped
backslashes. json() creates invalid JSON, and json_valid() happily
accepts it:

  $ sqlite3
  SQLite version 3.15.1 2016-11-04 12:08:49
  Enter ".help" for usage hints.
  Connected to a transient in-memory database.
  Use ".open FILENAME" to reopen on a persistent database.
  sqlite> select json('" \ "'); -- Creates invalid JSON
  " \ "
  sqlite> select json('" \\ "');
  " \\ "
  sqlite> select json_valid('" \ "'); -- Accepts invalid JSON
  1
  sqlite> select json_quote('\'); -- Works correctly
  "\\"
  sqlite>

  $ sqlite3 :memory: "select json('\" \\ \"');"
  " \ "
  $ sqlite3 :memory: "select json('\" \\ \"');" | json_verify
  lexical error: inside a string, '\' occurs before a character which it
  may not.
  " \ "
   (right here) --^
  JSON is invalid
  $

It's been like this since JSON arriveed in v3.9.0.

And oh, thanks for creating this wonderful piece of software.

Regards,
Øyvind
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Wish List for 2016: High Level API for Object Oriented Interactive Languages

[Darren Duncan]

On 2016-11-06 3:50 AM, vfclists . wrote:

On 8 January 2016 at 01:47, Stephen Chrzanowski  wrote:

I personally wish the reverse.  I wish that these interpreted language
engines would incorporate the SQLite code directly into their own existence
to avoid having to write wrappers to begin with, except for those wrappers
where their method name is "DatabaseOpen" and I prefer "OpenDatabase".

SQLite has been around for years, and "R", PHP, Java, Perl, and all these
other interpreted new and old style languages have never bothered to
incorporate this public domain database engine within itself.  It isn't
like the maintainers of these languages don't know it doesn't exist, and if
they didn't, then my god they gotta get out from under that rock.  Most web
browsers use SQLite for crying out loud.

For a few years, I've considered taking the entire amalgamation and porting
it to Pascal (Delphi/FPC) so I have exactly zero reliance on DLLs.  No
worries about OBJ files, no worries about dependencies, I just include a
unit and my app is now database aware.  I know 386 assembly, and I can
always read up on other specifications if I needed to.  My problem is that
gaming gets in the way.

My 2016 wish list for SQLite is that all developers who write for, or use
directly or indirectly, any database engine out on the market has a safe
and happy 2016 and beyond.


Haven't the mORMot guys already done this -
http://synopse.info/fossil/wiki?name=SQLite3+Framework? I think they have a
means of compiling sqlite access directly into Delphi and Freepascal.


If anyone feels like replying to the quoted message or thread starter, dated 
2016 January 7 PST, please first look at the SQLite list archives for Jan 7-8 
first as a discussion already occurred then.  I personally think the subject has 
already run its course. -- Darren Duncan


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Wish List for 2016: High Level API for Object Oriented Interactive Languages

[vfclists .]

On 8 January 2016 at 01:47, Stephen Chrzanowski  wrote:

> I personally wish the reverse.  I wish that these interpreted language
> engines would incorporate the SQLite code directly into their own existence
> to avoid having to write wrappers to begin with, except for those wrappers
> where their method name is "DatabaseOpen" and I prefer "OpenDatabase".
>
> SQLite has been around for years, and "R", PHP, Java, Perl, and all these
> other interpreted new and old style languages have never bothered to
> incorporate this public domain database engine within itself.  It isn't
> like the maintainers of these languages don't know it doesn't exist, and if
> they didn't, then my god they gotta get out from under that rock.  Most web
> browsers use SQLite for crying out loud.
>
> For a few years, I've considered taking the entire amalgamation and porting
> it to Pascal (Delphi/FPC) so I have exactly zero reliance on DLLs.  No
> worries about OBJ files, no worries about dependencies, I just include a
> unit and my app is now database aware.  I know 386 assembly, and I can
> always read up on other specifications if I needed to.  My problem is that
> gaming gets in the way.
>
> My 2016 wish list for SQLite is that all developers who write for, or use
> directly or indirectly, any database engine out on the market has a safe
> and happy 2016 and beyond.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


Haven't the mORMot guys already done this -
http://synopse.info/fossil/wiki?name=SQLite3+Framework? I think they have a
means of compiling sqlite access directly into Delphi and Freepascal.

-- 
Frank Church

===
http://devblog.brahmancreations.com
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users