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)
|
> 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.