Back on 13 January, I posted in the Learn forum some questions regarding using Postgres and got a reply that stated the following:

On Monday, 15 January 2018 at 02:28:29 UTC, Matthias Klumpp wrote:
> In any case, please don't start another Postgres library and consider contributing to one of the existing ones, so that we maybe have one really awesome, 100% complete library at some point.

I'm revisiting this because I now have had the chance to look at the various libraries and IMHO the "really awesome, 100% complete library" depends on the users' goals and their definition of awesome and complete.

Aside from ddbc which is like ODBC/JDBC and thus supports multiple db's (not my interest), I've found five Postgres-specific libraries worthy of further exploration:

1. derelict-pq. This is the most downloaded one and is simply a binding over libpq, so AFAICT it's nearly 100% complete. It's also well-documented, in part because the Derelict libraries provide overall guidance, but mainly because a D user can refer directly to the comprehensive libpq documentation and (C) examples. The only strange fact is that it's been stuck in a beta.3 release for the last five months.

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.

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

4. ddb. About the same number of downloads as the above. Implemented on top of front/backend protocol. No documentation although repository has a folder with two sample programs.

5. dpq. Implements its own wrapper over libpq and has some ORM functionality. Docs are a README with example program.

The main issue is that, other than derelict-pq, using any of these libraries involves reading the library code and understanding the sui generis interfaces implemented by each.

I'm new to the D community, but coming from Python, the contrast is significant. First there is the well-documented PEP 249 (https://www.python.org/dev/peps/pep-0249/) promulgated by the Python DB-SIG (and note that 249 is v.2), which led to the implementation of psycopg (also well-documented including various extensions to the API) and many other adapters to Postgres and other databases.

Since I'm new, I don't know if there's any interest in moving in such a direction.

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.

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.

Hi Joe and Rikki,

This is the goal of my dstddb project and I've picked it up again after a long hiatus.    I do have limited support for a native postgres driver and there is plenty of work to do in general, but I'm working on it.   I have some type support improvements for postgres that will arrive shortly.

erik

On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote:
> Back on 13 January, I posted in the Learn forum some questions regarding using Postgres and got a reply that stated the following:
>
> On Monday, 15 January 2018 at 02:28:29 UTC, Matthias Klumpp wrote:
>> In any case, please don't start another Postgres library and consider contributing to one of the existing ones, so that we maybe have one really awesome, 100% complete library at some point.
>
> I'm revisiting this because I now have had the chance to look at the various libraries and IMHO the "really awesome, 100% complete library" depends on the users' goals and their definition of awesome and complete.
>
> Aside from ddbc which is like ODBC/JDBC and thus supports multiple db's (not my interest), I've found five Postgres-specific libraries worthy of further exploration:
>
> 1. derelict-pq. This is the most downloaded one and is simply a binding over libpq, so AFAICT it's nearly 100% complete. It's also well-documented, in part because the Derelict libraries provide overall guidance, but mainly because a D user can refer directly to the comprehensive libpq documentation and (C) examples. The only strange fact is that it's been stuck in a beta.3 release for the last five months.
>
> 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.
>
> 3. vibe-d-postgresql. Third most downloaded and built on top of dpq2. Docs consist of a single example program.
>
> 4. ddb. About the same number of downloads as the above. Implemented on top of front/backend protocol. No documentation although repository has a folder with two sample programs.
>
> 5. dpq. Implements its own wrapper over libpq and has some ORM functionality. Docs are a README with example program.
>
> The main issue is that, other than derelict-pq, using any of these libraries involves reading the library code and understanding the sui generis interfaces implemented by each.
>
> I'm new to the D community, but coming from Python, the contrast is significant. First there is the well-documented PEP 249 (https://www.python.org/dev/peps/pep-0249/) promulgated by the Python DB-SIG (and note that 249 is v.2), which led to the implementation of psycopg (also well-documented including various extensions to the API) and many other adapters to Postgres and other databases.
Some developers spend hours writing code but don't feel the need to speed minutes documenting or at least showing how to use their code. Part of the reason others roll their own (one they will understand).  Goes on and on.

If its for their personal use,  then they shouldn't put it on dub to saturate the ecosystem.

I sometimes go around sending pull requests to some with sample I got from their unittests or "example"  folder. Worst case,  they send you a link to the C library they wrote bindings for... "oh its easy to know by looking at the C docs". Some don't even border... this is common with C libraries. C has libs but hard to figure out how to use without going through code.

Laugh at,  as one may,  Javascript npm libraries are well documented so there's high adoption. OP even agrees derelict-pq is well documented so it has a higher usage. All Dub libraries with good docs are those that are downloaded. Most importantly, a description of package and a sample/demo is the README.md file. A link to generated docs may follow to more info. Only generated docs don't cut it.


If you document your code well,  others will use and contribute to it without rolling their own. Docs on library purpose and sample usage at least.

> "The most used Dub libraries are those well documented."

On Saturday, 24 February 2018 at 07:57:47 UTC, aberba wrote:
> On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote:

>> 4. ddb. About the same number of downloads as the above. Implemented on top of front/backend protocol. No documentation although repository has a folder with two sample programs.

> Some developers spend hours writing code but don't feel the need to speed minutes documenting or at least showing how to use their code. Part of the reason others roll their own (one they will understand).  Goes on and on.

Have you tried to generate the documentation?

Look for example inside the source files...

https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/postgres.d#L2

https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/db.d#L19

/Paolo

On Saturday, 24 February 2018 at 08:32:38 UTC, Paolo Invernizzi wrote:
> On Saturday, 24 February 2018 at 07:57:47 UTC, aberba wrote:
>> On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote:
>
>>> 4. ddb. About the same number of downloads as the above. Implemented on top of front/backend protocol. No documentation although repository has a folder with two sample programs.
>
>> Some developers spend hours writing code but don't feel the need to speed minutes documenting or at least showing how to use their code. Part of the reason others roll their own (one they will understand).  Goes on and on.
>
> Have you tried to generate the documentation?
>
> Look for example inside the source files...
>
> https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/postgres.d#L2
>
> https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/db.d#L19
>
> /Paolo

Worst case answer I just talked about

On Saturday, 24 February 2018 at 09:10:03 UTC, aberba wrote:
> On Saturday, 24 February 2018 at 08:32:38 UTC, Paolo Invernizzi wrote:
>> On Saturday, 24 February 2018 at 07:57:47 UTC, aberba wrote:
>>> On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote:
>>
>>>> 4. ddb. About the same number of downloads as the above. Implemented on top of front/backend protocol. No documentation although repository has a folder with two sample programs.
>>
>>> Some developers spend hours writing code but don't feel the need to speed minutes documenting or at least showing how to use their code. Part of the reason others roll their own (one they will understand).  Goes on and on.
>>
>> Have you tried to generate the documentation?
>>
>> Look for example inside the source files...
>>
>> https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/postgres.d#L2
>>
>> https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/db.d#L19
>>
>> /Paolo
>
> Worst case answer I just talked about

I think no...

The documentation on how to use the package is present, it's just inside the modules as Ddoc documentation.

Joe, you can easily 'extract' it using the proper -D compiler switch

/Paolo

On Saturday, 24 February 2018 at 07:57:47 UTC, aberba wrote:
> On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote:
>> Back on 13 January, I posted in the Learn forum some questions regarding using Postgres and got a reply that stated the following:
>>
>> On Monday, 15 January 2018 at 02:28:29 UTC, Matthias Klumpp wrote:
>>> In any case, please don't start another Postgres library and consider contributing to one of the existing ones, so that we maybe have one really awesome, 100% complete library at some point.
>>
>> I'm revisiting this because I now have had the chance to look at the various libraries and IMHO the "really awesome, 100% complete library" depends on the users' goals and their definition of awesome and complete.
>>
>> Aside from ddbc which is like ODBC/JDBC and thus supports multiple db's (not my interest), I've found five Postgres-specific libraries worthy of further exploration:
>>
>> 1. derelict-pq. This is the most downloaded one and is simply a binding over libpq, so AFAICT it's nearly 100% complete. It's also well-documented, in part because the Derelict libraries provide overall guidance, but mainly because a D user can refer directly to the comprehensive libpq documentation and (C) examples. The only strange fact is that it's been stuck in a beta.3 release for the last five months.
>>
>> 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.
>>
>> 3. vibe-d-postgresql. Third most downloaded and built on top of dpq2. Docs consist of a single example program.
>>
>> 4. ddb. About the same number of downloads as the above. Implemented on top of front/backend protocol. No documentation although repository has a folder with two sample programs.
>>
>> 5. dpq. Implements its own wrapper over libpq and has some ORM functionality. Docs are a README with example program.
>>
>> The main issue is that, other than derelict-pq, using any of these libraries involves reading the library code and understanding the sui generis interfaces implemented by each.
>>
>> I'm new to the D community, but coming from Python, the contrast is significant. First there is the well-documented PEP 249 (https://www.python.org/dev/peps/pep-0249/) promulgated by the Python DB-SIG (and note that 249 is v.2), which led to the implementation of psycopg (also well-documented including various extensions to the API) and many other adapters to Postgres and other databases.
> Some developers spend hours writing code but don't feel the need to speed minutes documenting or at least showing how to use their code. Part of the reason others roll their own (one they will understand).  Goes on and on.
>
> If its for their personal use,  then they shouldn't put it on dub to saturate the ecosystem.
>
> I sometimes go around sending pull requests to some with sample I got from their unittests or "example"  folder. Worst case,  they send you a link to the C library they wrote bindings for... "oh its easy to know by looking at the C docs". Some don't even border... this is common with C libraries. C has libs but hard to figure out how to use without going through code.
>
> Laugh at,  as one may,  Javascript npm libraries are well documented so there's high adoption. OP even agrees derelict-pq is well documented so it has a higher usage. All Dub libraries with good docs are those that are downloaded. Most importantly, a description of package and a sample/demo is the README.md file. A link to generated docs may follow to more info. Only generated docs don't cut it.
>
>
> If you document your code well,  others will use and contribute to it without rolling their own. Docs on library purpose and sample usage at least.
>
>> "The most used Dub libraries are those well documented."
+1
I want to subscribe to this.
To improve the D ecosystem it would be a plus point to mark all libs at code.dlang.org having documentation with a special sign.

Most people want a solution for their problems, they don't want to make an analysis,
which of n available libs is best to use. Most more widely adopted languages offer
the needed DB connectors in their std.

The medium step between expanding the std lib and having nothing official might be,
to try to adopt more for the dlang git repro. (https://github.com/dlang-community)
(As mentioned before)

Even if the first choice might be not the best of all available libs for one problem,
if the community has started to develop _one_ solution for a problem, the value of contributing to this increases dramatically. I think the community is not big enough to support five different well documented, well designed and understood libs for solving the same problem.
Regards mt.

On Saturday, 24 February 2018 at 06:05:38 UTC, Erik Smith 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.
>
> Hi Joe and Rikki,
>
> This is the goal of my dstddb project and I've picked it up again after a long hiatus.    I do have limited support for a native postgres driver and there is plenty of work to do in general, but I'm working on it.   I have some type support improvements for postgres that will arrive shortly.
>
> erik

I wish it have designed in http://code.dlang.org/packages/mysql-native style. This driver IMHO is very well designed

On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote:
> 3. vibe-d-postgresql. Third most downloaded and built on top of dpq2. Docs consist of a single example program.

If you write docs and examples, I'd expect vibe to accept them, but ask them anyway.