On Sunday, 25 February 2018 at 15:34:00 UTC, Joe wrote:
On Sunday, 25 February 2018 at 09:07:34 UTC, Denis F wrote:
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.
I don't see how making libraries compatible with each other,
i.e., complying with some standard, will result in losing
functionality. What I'm talking about is standardizing the
names of certain classes and their methods, exceptions, and
perhaps some datatypes and the expected order of certain
arguments. For example, instead of having classes named
Database (sqlite3), PGConnection (ddb) and Connection (dpq2,
mysql-native) there's just one name, and that class is expected
to have certain methods.
I guess this is problem too: sqlite isn't connects at all, and
its struct represents RDBMS itself. But other should represent
only connections because they manipulate the connection and not
controls its server, and connection is a potential source of
connection-related exceptions. This is a subtle but important
difference too.
The library implementor can add others. For example, I see
mysql-native has a connection pool and that doesn't need to be
part of the standard. Also, some methods can be specified as
being optional by the standard, e.g., something like callproc,
because not all DBMSs support procedures.
This is another confirmation is that there are more differences
than similarities between databases. :-)
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.)
In PEP 249, this was left up to the implementors (see the
paramstyle global), but a footnote suggests that some styles
are supposed to be preferred over others.
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.
I'm not sure I understand your example, but perhaps this is
getting too specific and close to the discussions that would
need to take place betweeen existing implementors. There has
to be a negotiation process for a standard to be developed. In
my example above, suppose the sqlite3 library developer says "I
don't want to have a class named Connection, because my users
don't connect to a server". It will be up to the other
developers to convince him or to arrive at some compromise
What are these sacrifices for? I do not like idea that I should
drop some functionality of Postgres for conpatibility with
another RDBMSes. Personally, I like specific databases because it
have nuances of functionality that they provide to me.
And those who wish to "crossbreeding a hedgehog with a snake", at
first, can try to write a wrapper around existing SQL libraries.
This is faster and more humane in relation to the developers.
