Marcin Kuszczak wrote:
...
My db access layer solves above problems.
You have me drooling in anticipation.
How does it work?
1. First it is necessary to define database schema. For this purpose I
use special classes derived from IColumn. In this case it would be
IDbTypedColumn. When defining database schema I define types of columns,
and also constraints for db column. In D it is possible to generate
schema classes from schema definition file on compile time, and in fact
it is already working in my project Doost (see: db package).
public DbTypedColumn<Integer> id = new DbTypedColumn<Integer>("id",
visitcards, new Integer[0], new DbConstraints().primaryKey());
From this, it looks like this would be a good base for anyone wanting
to build an ORM package -- it'd mainly leave translation between objects
and columns.
2. Column defined in db schema are used when defining queries to
database. Because column definitions are typed, it is also possible to
check types of arguments when defining queries.
Script script = Create(vcards_db.instance()).IfNotExists();
Query query = Select(visitcards).Where(Equals(visitcards.id, 5));
Hm. Fluent interfaces are good. Domain-specific languages can be easier
to work with, but they take a lot more effort to create and maintain.
If you or someone else wanted to help in such a framework (I will use
probably BSD license) I will put code somewhere, so it will be possible
to work on it together. In such a case please drop me an email. First
thing to do is to rethink architecture and found even better ways of
doing things... :-)
I'm quite interested in this. I might have time to help out, but I'm not
going to make any offers I might not be able to fulfill.
