On Sunday, 14 February 2016 at 16:53:31 UTC, Piotr Szturmaj wrote:
On 2016-02-14 12:48, Jacob Carlborg wrote:
It seems both ddb and ddbc had the same idea, building a
accessing databases independently of the kind of database. The
difference is that ddb does not seem to have the abstraction
database independent and only works for Postgres. ddbc on the
does support multiple databases and have the abstraction
layer. So at
this point ddb is basically a Postgres driver and nothing more.
ddb was written with multiple databases in mind, mostly
postgres, mysql and sqlite. db.d (DBRow definition) is database
independent. postgres.d contains PGConnection, PGCommand, etc.
Other backends should provide their own classes like
MySqlConnection, MySqlCommand and so on. Then it's trivial to
add an abstraction layer that chooses between different
backends depending on the connection string for example.
Regarding ddb maintainability, thank you for your interest, I
can add you both (Jacob and Eugene) to my repository as
collaborators, you will have full access to repo, pull requests
and issues. If I will ever need ddb in some of my project I
would still have access to my repo to make some changes. If the
project will grow bigger than expected we could move it to the
new repo later. Is that okay for you?
yes, it is for sure ok for me. It can be a good start.
I think may be we should discuss if we can/should change
something in ddb. I think there were some interesting and
promising ideas in this discussion. Maybe split the PostgreSQL
driver and develop it seperately and use an interface more
similar to JDBC. Maybe some kind of coworking with ddbc is
possible to get more developers together; maybe Suliman has some
thoughts on it.