On 2016-02-14 12:48, Jacob Carlborg wrote:
It seems both ddb and ddbc had the same idea, building a library
accessing databases independently of the kind of database. The
difference is that ddb does not seem to have the abstraction making it
database independent and only works for Postgres. ddbc on the other hand
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?