Email list hosting service & mailing list manager

World's simplest Scheme interface to sqlite3 John Cowan (29 Aug 2020 03:00 UTC)
(missing)
(missing)
Fwd: World's simplest Scheme interface to sqlite3 John Cowan (29 Aug 2020 17:57 UTC)
Re: Fwd: World's simplest Scheme interface to sqlite3 Lassi Kortela (29 Aug 2020 18:44 UTC)
Re: Fwd: World's simplest Scheme interface to sqlite3 John Cowan (29 Aug 2020 22:37 UTC)
SQL API sketch with some code Lassi Kortela (30 Aug 2020 13:24 UTC)
Re: SQL API sketch with some code Lassi Kortela (30 Aug 2020 13:46 UTC)
Re: SQL API sketch with some code John Cowan (30 Aug 2020 20:47 UTC)
Re: SQL API sketch with some code Lassi Kortela (31 Aug 2020 05:02 UTC)
Re: SQL API sketch with some code Lassi Kortela (31 Aug 2020 05:14 UTC)
Re: SQL API sketch with some code John Cowan (31 Aug 2020 15:38 UTC)
Re: SQL API sketch with some code Lassi Kortela (31 Aug 2020 15:54 UTC)
Re: SQL API sketch with some code John Cowan (31 Aug 2020 17:12 UTC)
Re: SQL API sketch with some code Lassi Kortela (31 Aug 2020 19:20 UTC)
Reflection on the database schema Lassi Kortela (30 Aug 2020 13:35 UTC)
Re: Reflection on the database schema John Cowan (30 Aug 2020 19:51 UTC)
Re: Fwd: World's simplest Scheme interface to sqlite3 Alaric Snell-Pym (31 Aug 2020 22:03 UTC)
Re: Fwd: World's simplest Scheme interface to sqlite3 Lassi Kortela (02 Sep 2020 08:38 UTC)
Re: Fwd: World's simplest Scheme interface to sqlite3 John Cowan (02 Sep 2020 17:09 UTC)
SQL statement caching Lassi Kortela (02 Sep 2020 17:21 UTC)
Re: SQL statement caching John Cowan (02 Sep 2020 18:13 UTC)
Re: SQL statement caching Lassi Kortela (02 Sep 2020 18:53 UTC)
Re: World's simplest Scheme interface to sqlite3 Lassi Kortela (29 Aug 2020 11:40 UTC)
Re: World's simplest Scheme interface to sqlite3 Ivan Raikov (29 Aug 2020 04:06 UTC)
Re: World's simplest Scheme interface to sqlite3 Lassi Kortela (29 Aug 2020 11:24 UTC)
Re: World's simplest Scheme interface to sqlite3 John Cowan (29 Aug 2020 17:47 UTC)
Re: World's simplest Scheme interface to sqlite3 Lassi Kortela (29 Aug 2020 18:23 UTC)
Re: World's simplest Scheme interface to sqlite3 John Cowan (29 Aug 2020 22:15 UTC)
Re: World's simplest Scheme interface to sqlite3 Amirouche Boubekki (29 Aug 2020 07:33 UTC)
Re: World's simplest Scheme interface to sqlite3 Lassi Kortela (29 Aug 2020 11:37 UTC)

Re: Fwd: World's simplest Scheme interface to sqlite3 Lassi Kortela 29 Aug 2020 18:44 UTC

> The difference between -exec and -eval is that -exec returns the number
> of results whereas -eval returns the (first) result.

In practice, the useful ones are:

- I expect to receive exactly one scalar (i.e. one row with one column).

- I expect to receive exactly one vector (i.e. one row with with one or
more columns).

- I expect to receive zero or more vectors (i.e. zero or more rows, each
with one or more columns).

https://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-19.html says
sqlite-exec returns the first "element" and sqlite-eval returns the
first "value". sqlite-eval additionally filters the value through a
user-supplied procedure. sqlite-map is like sqlite-eval done to all values.

It looks like "select a, b, c from foo" causes 3 values per row to be
returned to Scheme, so (the-user-supplied-procedure a b c) is applied on
the Scheme side by map. Maybe element means what I mean by scalar above.

> I'm also thinking that make-sqlite-generator is a better approach than
> sqlite-map.  That way you get map and foreach and ->list and everything
> you might want.

Agreed, but see above.

> There are three more procedures, which I think are the bare minimum
> amount of reflectivity:
>
> 7) -table-names returns a list of the names of tables.
>
> 8) -column-names returns a list of column names correctly ordered, given
> the name of a table.
>
> 9) -last-rowid returns the rowid of the last insertion, which gives
> fairly direct access to the newly inserted row (unless the table is
> rowid-free, as some are).

Last I checked, row IDs are essentially non-portable in SQL land. Maybe
things have changed. Yes, this is meant to be a SQLite SRFI, but code
relying on rowIDs may still be a sign that we're doing something too clever.

-table-names and -column-names can be done with ordinary SQL (by
querying magic SQLite-only tables). Do they need their own procedures?

> Update:
>
> When I say sql-format comes out, I still want to retain some of its
> features.  Let's see how far we can get with just a (name . object)
> alist, where names appear in the string delimited by ? or whatever,
> without any type information:
>
> Object is a string.  Escape it properly.
>
> Object is a symbol.  Assume it's a table, column, etc. name, escape it
> properly.
>
> Object is a number.  Make sure it's a real number and use number->string
> on it.  No escaping needed.
>
> Object is a bytevector:  Convert to hex format:  x'4142430A'.
>
> Object is a list of symbols.  Escape them as names, join with comma.
>
> Object is a list of strings.  Escape them as strings, join with comma.
>
> Object is a procedure.  Invoke it, insert the string result unescaped in
> any way.
>
> Anything else needed?  Note that some but not all of these can be done
> with SQLite "?" or "?n" markers.

I've used SQLite a fair amount, also abusing it to do things it's not
really supposed to do and which are probably in bad taste, and I don't
think I ever needed escaping for anything other than messing with "alter
table" and the like. Can't SQLite do everything else with question marks?

Being able to feed it real numbers and bytevectors is great, and
converting symbols to strings is probably okay, but these are orthogonal
to escaping.