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

On Saturday, 24 February 2018 at 23:17:46 UTC, Denis F wrote:
> On Saturday, 24 February 2018 at 22:24:58 UTC, bachmeier wrote:
>> 3. Looking at the source code, you have already written a bunch of comments. Those are documentation once you turn them into html.
>
> I'm for the comments to be documentation. But I am paranoid and do not like that the  documentation generator should be granted write access to the repository.

If you talk about using Travis to build the documentation and push to gh-pages like e.g explained here [1]. There are solutions:

a) Use branch protection (GH offers this. No one can force push something to protected branches)
b) Use a dedicated bot account (if you are worried about leaking the credentials)
c) Use a dedicated *-docs repo to which Travis pushes
d) Push to a different location (e.g. S3, netlify
...

[1] https://forum.dlang.org/post/tkcndtapfypabsncxxla@forum.dlang.org

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.

On Sunday, 25 February 2018 at 03:20:08 UTC, Seb wrote:

> If you talk about using Travis to build the documentation and push to gh-pages like e.g explained here [1]. There are solutions:
>
> a) Use branch protection (GH offers this. No one can force push something to protected branches)
> b) Use a dedicated bot account (if you are worried about leaking the credentials)
> c) Use a dedicated *-docs repo to which Travis pushes
> d) Push to a different location (e.g. S3, netlify
> ...
>
> [1] https://forum.dlang.org/post/tkcndtapfypabsncxxla@forum.dlang.org

Thank! I will try to solve this

On 25/02/2018 10:07 PM, Denis F wrote:
> 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.)

On IRC earlier today we discussed database libs a bit, we agreed that both "?" and "@name" needed to be supported. No other suggestions came up. We don't really need a third or fourth form I think.

On Sunday, 25 February 2018 at 09:23:18 UTC, rikki cattermole wrote:

>>> 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.)
>
> On IRC earlier today we discussed database libs a bit, we agreed that both "?" and "@name" needed to be supported. No other suggestions came up. We don't really need a third or fourth form I think.

...And you are planned to give up "$1" support in favor of '?' and ":name"?

But it is impossible to convert text :names or '?' into Postgres's "$1": Postgres isn't knows fields names at start of a query processing and you can't replace '?' to "$<num>" by simple 'replace' call - it will need full syntax parsing of Posgres SQL query because queries can contain EXECUTE statement (whose purpose is executing dynamic commands).

On 26/02/2018 12:46 AM, Denis F wrote:
> On Sunday, 25 February 2018 at 09:23:18 UTC, rikki cattermole wrote:
> 
>>>> 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.)
>>
>> On IRC earlier today we discussed database libs a bit, we agreed that both "?" and "@name" needed to be supported. No other suggestions came up. We don't really need a third or fourth form I think.
> 
> ...And you are planned to give up "$1" support in favor of '?' and ":name"?
> 
> But it is impossible to convert text :names or '?' into Postgres's "$1": Postgres isn't knows fields names at start of a query processing and you can't replace '?' to "$<num>" by simple 'replace' call - it will need full syntax parsing of Posgres SQL query because queries can contain EXECUTE statement (whose purpose is executing dynamic commands).

Let's not go inventing a solution here, what does JDBC and ADO.net do?

On Sunday, 25 February 2018 at 12:12:58 UTC, rikki cattermole wrote:

> Let's not go inventing a solution here, what does JDBC and ADO.net do?

JDBC isn't touches this - it is just passes statement "as is". I.e. it isn't drops support of any type of args.

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

On Sunday, 25 February 2018 at 09:23:18 UTC, rikki cattermole wrote:
> On IRC earlier today we discussed database libs a bit, we agreed that both "?" and "@name" needed to be supported. No other suggestions came up. We don't really need a third or fourth form I think.

"@name"? Which DBMS uses that? Although Denis said Postgres uses $1, PG also supports :name, in either the command line tool (psql) and the procedural language PL/pgSQL.  Personally, I prefer what Python's PEP 249 calls 'format' (%s) or 'pyformat' (%(name)s).  Note that although the %s appears in the SQL string, the actual arguments are passed separately at invocation time, as either tuples or dicts (associative arrays).

Joe