> From: Alaric Snell-Pym <xxxxxx@snell-pym.org.uk>
> Subject: Re: How can we handle as many quirks as possible in general fashions?
> Date: Wednesday, September 18, 2019 10:28 AM
>
> On 18/09/2019 15:24, xxxxxx@ancell-ent.com wrote:
>
> [ On how and where to specify data type mappings for returned values. ]
>
>>> In fact, I suspect the values of the alist should probably be a list of
>>> values obtained from bindings exported from the DBI or DBD modules, or
>>> the results of calling procedures exported from same:
>>
>> My ideal is that the DBI level won't be parsing any part of queries or
>> other statements, it should be query language agnostic, the thin wrapper
>> you mention below, and let the levels above and below deal with this.
>
> Maaaaybe...

I'm not sure myself, but I see the following advantages if it can be
pulled off without significantly increasing complexity for the user:

- Could provide a common interface for some fraction of non-SQL databases
  more sophisticated than KVMs that have similar interaction styles, that
  is, it would be a true DBI, vs. a RDBI.

- If this DBI layer doesn't know query languages, let alone SQL, it
  can't capture any common quirks of that sort from the initial
  databases we'll support.  Although that'll bring more risk we'll miss
  something   necessary for an important database not in the first group.

- It enforces one important separation of concerns.

The full stack would look something like this:

  user code
  -
  maybe a framework
  -
  user-friendly procedures like in the PostgreSQL egg
  -
  DBI knows interaction patterns e.g. connect, operations, transactions
  -
  DBD data knows about the particular database's data types
  -
  DBD interface knows the Scheme and interfacing to particular database
  -
  There might be a layer here to fan out the different methods below
  -
  What John and Lassi are working on, or FFI, wire protocol, whatever
  -
  Database

The DBI would also have one or more libraries for standard mappings
of Scheme types to and from standard database data types, and those
would normally be called by default, as would some of the DBD layer's
type library for mappings for its non-standard or non-existent types.

The idea being that the user only has to be explicit about mapping
when necessary, because he's doing something non-standard, or he's
using a database with legacy data, etc.

A possibly significant wrinkle in achieving that automagic is the
limitations of a particular database's introspection capabilities
as Peter Bex mentioned, which would require a facility in our stack
to manually? fill in the gaps.

- Harold