Db access design - call for comments (& help)

[Christopher Wright]

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.