On Saturday, 24 February 2018 at 15:44:49 UTC, Paolo Invernizzi wrote:
> Joe: I think this is also a terrific 'welcome aboard' about how fast and quickly things can be done in D!

I'm a bit overwhelmed by all the replies and "goodies" but I'd like to say thanks to Adam while I digest it all.

Joe

On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote:

> 2. dpq2. Second most downloaded and built on top of derelict-pq. The "documentation" consists of a README listing the features and a single example, which appears to focus on support for JSON/BSON.

Hi! Here is dpq2 and vibe-d-postgresql developer.

The problem is that I do not know English very well. So,I think it's better not to write any documentation than to write the wrong one.

PRs are welcomed!

> 3. vibe-d-postgresql. Third most downloaded and built on top of dpq2. Docs consist of a single example program.

On Saturday, 24 February 2018 at 05:45:45 UTC, rikki cattermole wrote:
> There is plenty of desire to build a generalized SQL interface for Phobos.
>
> But somebody needs to do it and it won't be all that much fun to do.

I want to dwell on this.

It seems to me that this is a common misconception that it is possible to create a good universal tool for accessing the database in place of the many existing ones.

SQL is something like BASIC from the 70-80s: there is no single standard, there are many dialects. And the differences are both syntactic and deep, for example, Postgres and Oracle differently interpret the ANSI standard concerning transactions. The same applies to the connection layer: some of the databases allow you to organize a gradual download of the results, some - feedback in the form of something like "events", etc. Also, Postgres quarantiees that result of query will be immutable and this is very useful, but some one another DB maybe not.

At best, such a tool will be suitable for simple trivial things.

On the other hand, needing  for this is also not obvious - databases in real projects isn't switched usually every week/month because they are not interchangeable, except for some very simple cases. Usually RDBMS engine should be elected based on your requiriments before you start to use it.

On Saturday, 24 February 2018 at 18:56:23 UTC, Denis F wrote:
> Postgres quarantiees that result of query will be immutable

libpq, of course, not Postgres itself.

On Saturday, 24 February 2018 at 18:56:23 UTC, Denis F wrote:
> On Saturday, 24 February 2018 at 05:45:45 UTC, rikki cattermole wrote:
>> There is plenty of desire to build a generalized SQL interface for Phobos.
>>
>> But somebody needs to do it and it won't be all that much fun to do.
>
> I want to dwell on this.
>
> It seems to me that this is a common misconception that it is possible to create a good universal tool for accessing the database in place of the many existing ones.
>
> SQL is something like BASIC from the 70-80s: there is no single standard, there are many dialects. And the differences are both syntactic and deep, for example, Postgres and Oracle differently interpret the ANSI standard concerning transactions. The same applies to the connection layer: some of the databases allow you to organize a gradual download of the results, some - feedback in the form of something like "events", etc. Also, Postgres quarantiees that result of query will be immutable and this is very useful, but some one another DB maybe not.
>
> At best, such a tool will be suitable for simple trivial things.
>
> On the other hand, needing  for this is also not obvious - databases in real projects isn't switched usually every week/month because they are not interchangeable, except for some very simple cases. Usually RDBMS engine should be elected based on your requiriments before you start to use it.


I agree that the differences in both the client interface and the underlying SQL support are complicated issues.  However, it seems pretty clear that languages have some level of standardized db interface have benefited enormously in terms of adoption for building real word applications (JDBC for instance).  I think it is true people don't switch databases that much, but having a standard interface (especially one that is easy to use) that covers the most common uses cases does make the use of the platform itself that much more approachable.

Some of the differences can be hidden internally for the basic use case (such as gradual downloads) and optionally available as a introspective capability when the underlying driver supports it for more advanced usage.   The goal is to expose as much capability without overly complicating the interface.  This is easier to do now with modern abstractions then it was with ODBC in the 90's.

It would be good, however, to keep track of the specific problem areas that you mentioned to ensure that they are addressed well.

If one thing is clear from this thread, documentation is critical. I'm also aware that vibed support, for the databases that can most readily support it, is also a high priority.

erik

On Saturday, 24 February 2018 at 18:41:21 UTC, Denis F wrote:
> On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote:
>
>> 2. dpq2. Second most downloaded and built on top of derelict-pq. The "documentation" consists of a README listing the features and a single example, which appears to focus on support for JSON/BSON.
>
> Hi! Here is dpq2 and vibe-d-postgresql developer.
>
> The problem is that I do not know English very well. So,I think it's better not to write any documentation than to write the wrong one.
>
> PRs are welcomed!
>
>> 3. vibe-d-postgresql. Third most downloaded and built on top of dpq2. Docs consist of a single example program.

Well Denis, you may get your PR wish (but I don't have a timeframe). My interest is to develop something using Vibe.d, so I'll be delving more into these two first.

Joe

On Saturday, 24 February 2018 at 18:56:23 UTC, Denis F wrote:
> It seems to me that this is a common misconception that it is possible to create a good universal tool for accessing the database in place of the many existing ones.

I don't think what is needed a "good universal tool" but a good enough common interface. Python PEP 249 is very similar to what I've seen in the D libraries I've looked at: there is a Connection class of some kind, and a Cursor (or command or query) class, each with a set of well-defined (and generally not unexpected) methods: commit/rollback on the connection, execute/fetch/etc. on the cursor). PEP 249 also standardizes the exceptions and some datatypes.

It's not perfect, or universal enough, but I believe it allowed db development under Python to proceed at a faster pace than otherwise. There's a similar story on the web side. When Django first came out, IIRC it had its own interface, but then the WSGI standard came out (PEP 333) and every Python web framework including Django moved to it (it also resulted in a proliferation of frameworks, but that's another story). And WSGI even influenced Ruby's Rack and other such interfaces.

Joe

On Saturday, 24 February 2018 at 18:41:21 UTC, Denis F wrote:

> Hi! Here is dpq2 and vibe-d-postgresql developer.
>
> The problem is that I do not know English very well. So,I think it's better not to write any documentation than to write the wrong one.

There are still some steps you can take:

1. Put a statement on the project page encouraging people to create an issue if there is something not documented. Even better, have a Gitter community where they can post questions. You can create an example to show how it's done. Those examples can then be added to the project.

2. Decide on the common use cases for your library. Provide examples useful to someone getting started for each of the common use cases.

3. Looking at the source code, you have already written a bunch of comments. Those are documentation once you turn them into html.

On Saturday, 24 February 2018 at 20:45:03 UTC, Joe wrote:
> On Saturday, 24 February 2018 at 18:56:23 UTC, Denis F wrote:
>> It seems to me that this is a common misconception that it is possible to create a good universal tool for accessing the database in place of the many existing ones.
>
> I don't think what is needed a "good universal tool" but a good enough common interface. Python PEP 249 is very similar to what I've seen in the D libraries I've looked at: there is a Connection class of some kind, and a Cursor (or command or query) class, each with a set of well-defined (and generally not unexpected) methods: commit/rollback on the connection, execute/fetch/etc. on the cursor). PEP 249 also standardizes the exceptions and some datatypes.

Currently in dpq2 all of these things are implemented except cursors (I think cursors became "unpopular" lately)

>
> It's not perfect, or universal enough, but I believe it allowed db development under Python to proceed at a faster pace than otherwise.

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.

On Saturday, 24 February 2018 at 22:24:58 UTC, bachmeier wrote:
> On Saturday, 24 February 2018 at 18:41:21 UTC, Denis F wrote:
>
>> Hi! Here is dpq2 and vibe-d-postgresql developer.
>>
>> The problem is that I do not know English very well. So,I think it's better not to write any documentation than to write the wrong one.
>
> There are still some steps you can take:
>
> 1. Put a statement on the project page encouraging people to create an issue if there is something not documented. Even better, have a Gitter community where they can post questions. You can create an example to show how it's done. Those examples can then be added to the project.
>

Done!

> 2. Decide on the common use cases for your library. Provide examples useful to someone getting started for each of the common use cases.

What is a bad with example?

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