On Sunday, 25 February 2018 at 03:03:05 UTC, Joe wrote:
On Saturday, 24 February 2018 at 23:04:39 UTC, Denis F wrote:
If anyone really want to impliment your idea, at my first
glance at the PEP 249 I had a feeling that this is work for
time less than a 1-2 weeks. It can be a simple wrapper over
dpq2, mysql-native, sqlite3, etc.
I'm not saying that anyone should implement something like PEP
249, particularly *not* as a wrapper over those libraries. My
point is that if the implementors of dpq2, mysql-native, etc.,
could "get together" (at DConf, in forums, by email) and
discuss their interfaces, perhaps they could agree on a set of
D database interface classes and then each would work towards
that common set.
Libraries already are similar automatically because RDBMSes uses
similar principles. But it is impossible to make libraries
absolutely identical due to the presence of important significant
nuances in each engine.
That's more or less what the Python DB-SIG did. Then every
library would benefit because, for one, the common set can be
documented just once. Also, if it's a sufficiently reasonable
spec, the libraries that don't move towards it should see less
adoption because, unless the divergent library has a
significantly enhanced interface, developers will shy away from
having to learn a different one.
It's the same concept as the SQL (and other) Standards.
Ok, I propose to be consistent and ask for compliance with the
Standard from the RDBMSes. For example, arguments substitution:
MySQL uses the '?'
PostgreSQL uses $1
SQLite accepts both
Oracle uses a :name
(Really, it is very important to come to an agreement here
because, for sure, the next obvious step is writing an ORM
generator on top of the idea what you are proposing.)
There may be variances between implementations but no one has
implemented a RETRIEVE or PROJECT statement in lieu of a SELECT
statement (and note there *were* relational systems that used
the former).
For example, I would not change unobvious at first sight system
of classes "Result" and inherited from it class "Answer" for the
sake of similarity to other libraries. Simply because this is the
way what Postgres client library works, and if this classes will
be removed some significant functionality will be lost.
I'm sure that in other libraries there is something similar.