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?

Reply via email to