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. 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.
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 (in
the case of D an alias may be all that is needed to resolve such
an impasse).
Joe
