Database connections as subprocesses
Lassi Kortela
(14 Sep 2019 07:30 UTC)
|
||
Re: Database connections as subprocesses
John Cowan
(15 Sep 2019 01:06 UTC)
|
||
Re: Database connections as subprocesses
Lassi Kortela
(15 Sep 2019 06:28 UTC)
|
||
Re: Database connections as subprocesses
John Cowan
(15 Sep 2019 23:02 UTC)
|
||
Re: Database connections as subprocesses
Lassi Kortela
(16 Sep 2019 08:22 UTC)
|
||
Binary S-expressions
Lassi Kortela
(16 Sep 2019 17:49 UTC)
|
||
(missing)
|
||
Re: Binary S-expressions
Lassi Kortela
(17 Sep 2019 09:46 UTC)
|
||
Re: Binary S-expressions
Alaric Snell-Pym
(17 Sep 2019 11:33 UTC)
|
||
Re: Binary S-expressions
Lassi Kortela
(17 Sep 2019 12:05 UTC)
|
||
Re: Binary S-expressions
Alaric Snell-Pym
(17 Sep 2019 12:23 UTC)
|
||
Re: Binary S-expressions
Lassi Kortela
(17 Sep 2019 13:20 UTC)
|
||
Re: Binary S-expressions
Lassi Kortela
(17 Sep 2019 13:48 UTC)
|
||
Re: Binary S-expressions
Alaric Snell-Pym
(17 Sep 2019 15:52 UTC)
|
||
Re: Binary S-expressions hga@xxxxxx (17 Sep 2019 16:25 UTC)
|
||
Re: Binary S-expressions
rain1@xxxxxx
(17 Sep 2019 09:28 UTC)
|
||
Re: Binary S-expressions
Lassi Kortela
(17 Sep 2019 10:05 UTC)
|
||
Python library for binary S-expressions
Lassi Kortela
(17 Sep 2019 21:51 UTC)
|
||
R7RS library for binary S-expressions
Lassi Kortela
(17 Sep 2019 23:56 UTC)
|
||
Re: Database connections as subprocesses
Alaric Snell-Pym
(16 Sep 2019 08:40 UTC)
|
||
Re: Database connections as subprocesses
Lassi Kortela
(16 Sep 2019 09:22 UTC)
|
||
Re: Database connections as subprocesses
Alaric Snell-Pym
(16 Sep 2019 11:28 UTC)
|
||
Re: Database connections as subprocesses
hga@xxxxxx
(16 Sep 2019 13:28 UTC)
|
||
Re: Database connections as subprocesses
Lassi Kortela
(16 Sep 2019 13:50 UTC)
|
||
Re: Database connections as subprocesses
hga@xxxxxx
(17 Sep 2019 13:59 UTC)
|
||
Re: Database connections as subprocesses
John Cowan
(16 Sep 2019 22:41 UTC)
|
||
Re: Database connections as subprocesses
Lassi Kortela
(17 Sep 2019 09:57 UTC)
|
||
Re: Database connections as subprocesses
Lassi Kortela
(17 Sep 2019 10:22 UTC)
|
> From: Alaric Snell-Pym <xxxxxx@snell-pym.org.uk> > Date: Tuesday, September 17, 2019 10:52 AM > > On 17/09/2019 14:48, Lassi Kortela wrote: >> This is getting off-topic for a persistence list, but for lack of a >> better forum... > > Oh, I think it's relevant, because this is all about the encoding > between Scheme types and database values... Exactly. > Ideally, our drivers will do whatever is correct with the database at > hand to ensure that values of all types are correctly handled. Yes. Given that Scheme doesn't care about value types until you try to do something with a value, it's natural to put this layer in the database driver, between the generic database interface above, and the driver layer that directly talks to the database through an FFI, wire protocol, or whatever. > To support them in that, we need to define the types that are > supported. > > [ Fun with timestamps and time zones. ] > > As for strings... hopefully, the driver will negotiate with the > database to find out what encoding is expected, but IIRC with MySQL > this can vary between columns in the same database.... > > The best we can do there is probably to have a "default encoding" > set as part of the options when making a connection, maybe with the > option to override it per-column when binding strings into > queries.... Nasty, but sounds unavoidable. This is going to be a great deal of fun to scope and specify.... > [...] For normal users, we should magically do the right thing to > make their application correctly send strings to and from the > database; but we should also cater to "advanced" users having to > suffer that kind of work, if we must, perhaps by having some > mechanism to request that strings be returned from the DB as > bytevectors for them to do their own decoding on... Yes, we should pretty clearly have escape mechanisms for when we try to be clever, from a procedure that executes an arbitrary query language string, including returning multiple values like rows, to pass through binary data as you note. Very glad the way this discussion is exploring the design space! - Harold