Email list hosting service & mailing list manager

ODBC Lassi Kortela (11 Sep 2019 18:44 UTC)
Re: ODBC Duy Nguyen (12 Sep 2019 07:57 UTC)
Re: ODBC Peter Bex (12 Sep 2019 08:35 UTC)
ODBC, DBI and other generic database interfaces Lassi Kortela (12 Sep 2019 09:32 UTC)
DBI and transactions Lassi Kortela (12 Sep 2019 09:37 UTC)
Re: DBI and transactions Duy Nguyen (12 Sep 2019 09:40 UTC)
Re: DBI and transactions Peter Bex (12 Sep 2019 10:00 UTC)
Finishing nailing the coffin shut on ODBC? hga@xxxxxx (13 Sep 2019 15:17 UTC)
Re: Finishing nailing the coffin shut on ODBC? Lassi Kortela (13 Sep 2019 15:31 UTC)
Re: ODBC hga@xxxxxx (12 Sep 2019 11:52 UTC)
(missing)

Re: ODBC Peter Bex 12 Sep 2019 08:35 UTC
On Thu, Sep 12, 2019 at 02:57:26PM +0700, Duy Nguyen wrote:
> On Thu, Sep 12, 2019 at 1:44 AM Lassi Kortela <xxxxxx@lassi.io> wrote:
> >
> > This exists: <http://www.unixodbc.org/>
> >
> > I don't know anything about ODBC, but it's the first name that comes to
> > mind when thinking of a standard way to connect to different databases.

I dunno, from what I've seen it looks overengineered enterprise bullshit,
and old-fashioned as well (that unixodbc page hasn't been updated since
the nineties, it seems; it still refers to StarOffice as a thing).  I'd
love to hear from someone who has actual experience with the API, though.

> There's also Perl DBI, which is reimplemented(?) in Gauche as "dbi" module.

Having something like dbi would be useful in writing db-agnostic library
code (like in a framework, for example).

The DBI interface in Gauche seems useful, but it does sort of rely on
having an inheritance hierarchy.  At least, if you want to provide
non-standard extensions that would be done in the database-specific
subclass.  And I do think a way to have non-standard extensions is a
must when writing "serious" code.  Think for example about the COPY FROM
interface that Postgres offers, for fast data import/export.  And of
course things like custom data type registration.

Regarding inheritance, what's an accepted mechanism to do this?  SRFI-99,
SRFI-131, SRFI-150?  None of these are popular in CHICKEN, AFAICT.  We
do have coops, but that's neither super-popular nor standardised.
The standard R7RS records are SRFI-9 based and don't support
inheritance AFAIK.  Besides, what you really want is multimethods, for
which there is no SRFI.

Perhaps it's a better idea to define a common API that each module
exporting database stuff should implement.  Then for Schemes that support
functors (like CHICKEN), that could be one way of importing them in an
agnostic way, and a dbi-like functionality could be defined on top?

And with this sort of base, it would already be easy to switch out
one database for another in concrete code.  It would be tied to a
specific database, but at least if the API is the same, it's relatively
easy to change databases.

Cheers,
Peter