Email list hosting service & mailing list manager

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)

Re: Binary S-expressions hga@xxxxxx 17 Sep 2019 16:24 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