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. 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. 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).
Joe
