> 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
