Using postgres with vibe.d and ddb has been frustrating

Permalink: HTTP NNTP

Posted Sun, 09 Nov 2014 18:51:42 GMT

Reply

My time available for vibe.d-related projects is limited, and it has been severely frustrated by issues related to the database access, specifically due to ddb limitations.

My latest issue: it seems that ddb is not prepared for the current fiber to yield while a query has not been closed. Unfortunately, yielding is pretty much unavoidable :(

https://github.com/pszturmaj/ddb/issues/40

I wonder if it wouldn't be easier for me to just write my own Postgres/vibe.d driver.

How is this issue dealt with in the MongoDB driver?

Re: Using postgres with vibe.d and ddb has been frustrating

Permalink: HTTP NNTP

Sönke Ludwig

Posted Tue, 18 Nov 2014 18:58:13 +0100 in reply to Luís Marques

Reply

Am 09.11.2014 19:51, schrieb Luís Marques:

My time available for vibe.d-related projects is limited, and it has been severely frustrated by issues related to the database access, specifically due to ddb limitations.

My latest issue: it seems that ddb is not prepared for the current fiber to yield while a query has not been closed. Unfortunately, yielding is pretty much unavoidable :(

https://github.com/pszturmaj/ddb/issues/40

I wonder if it wouldn't be easier for me to just write my own Postgres/vibe.d driver.

How is this issue dealt with in the MongoDB driver?

I don't know anything about the DDB implementation, but does this mean
that it uses global variables to store state? Or is the problem with
accessing the same connection from multiple fibers/tasks?

In the latter case, it seems like there is a PostgresDB class that
contains a connection pool to deal with the issue. Using
db.lockConnection.someOperation(...) in each task should always use a
connection exclusive for that task, so that no protocol level issues
should arrise from yielding.

Re: Using postgres with vibe.d and ddb has been frustrating

Permalink: HTTP NNTP

Luís Marques

Posted Wed, 19 Nov 2014 13:12:14 GMT in reply to Sönke Ludwig

Reply

On Tue, 18 Nov 2014 18:58:13 +0100, Sönke Ludwig wrote:

In the latter case, it seems like there is a PostgresDB class that
contains a connection pool to deal with the issue. Using
db.lockConnection.someOperation(...) in each task should always use a
connection exclusive for that task, so that no protocol level issues
should arrise from yielding.

Yes, that was the solution. (Hat tip to etcimon, for the feedback on the github issue).

BTW, I suppose I was too quick to judge ddb on this issue, but that was due to previous frustrations with it :o)