Postgres and other database interfaces
Joe
jma at freedomcircle.com
Sun Feb 25 15:34:00 UTC 2018
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
More information about the Digitalmars-d
mailing list