Native D MySQL Driver

[Paulo Pinto]

You should not have any problems with ODBC on Windows regarding
licensing, I imagine.

After all you just need to code against the Win32 ODBC API. You
don't need to consider the real driver you are talking with.

--
Paulo

On 10.11.2011 18:54, Steve Teale wrote:
> I have pushed a first cut of the native MySQL driver to
>
> https://github.com/britseye
>
> The documentation can be seen at
>
> britseyeview.com/software/mysqln/
>
> I'm now investigating ODBC. That should be a fairly quick exercise, since
> I have already done ODBCD once, and I'm just doing a sketch at this
> point. I expect my conclusion to be that an almost identical interface is
> feasible. The licensing situation for ODBC on Linux appears to be OK. I
> can't speak for Windows - any thoughts? My primary target for an ODBC
> implementation is MS SQL Server. That could be done using the TDS
> protocol, but since FreeTDS have already been there and is LGPL, and we
> only need to link, I don't really want to go there.
>
> I can see from Piotr's work on PostgreSGL that an almost identical
> interface is possible for that too. The license there looks friendly too,
> but again comments please. SQLite is a bit different by its nature, but I
> think that it can closely fit the pattern too - no license problems there
> I think.
>
> I will write up a description of the interface I'm talking about in the
> next few days. This is what I see as the mid level interface, a set of
> modules - etc.mysql, etc.odbc, etc.postgres, etc.sqlite ...
>
> It needs to be discussed and at some point agreed so that the current
> 'team' can work toward it for the various databases.
>
> We've recently seen an example of an SQLite interface that demonstrated a
> higher level style where some of the burden of getting SQL right was
> dealt with by the API. I detected some interest in it. Any further
> opinions on that? The water gets quite deep quite quickly if you go in
> that direction though, and think about how more complex SQL commands
> might be represented, the diversity of SQL dialects, and so on. Somewhere
> out there I can see etc.postgres.traits and such.
>
> Sorry if this is rather long.
>
> Steve