Re: [boost] [rdb] 0.04

Subject: Re: [boost] [rdb] 0.04
From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2009-09-21 16:22:27

> I also happened to start casually working on this problem about a month ago
> without knowing anyone else was working on a similar solution.
Well my lib doesn't need to remain a one-man show. As the internals 
stabilize I hope that others jump in. All contributions will get 
credited of course.

> For the most part, I like Jean-Louis's solution better than my own, except
> that I think columns need to support column-constraints i.e. primary key,
> not null, unique, etc. Also, I'm thinking there will be a need for foreign
> keys to be defined.
>   
That will come  too. Like views. And maybe triggers.

Currently my roadmap is : CRUD via direct execution ; prepared 
statements ; placeholders ; transactions ; dialects (Postgres would be a 
good candidate because it has a non-standard syntax for escaping quotes 
in string literals). Along the way I (or someone else) will implement 
"easy" things like constraints and views.

I haven't thought a lot about the syntax of constraints yet. My first 
thoughts were to put them outside the table definition to avoid long 
arguments lists, e.g. BOOST_RDB_PRIMARY_KEY(Column) would specialize 
some template responsible for constarint creation. But your syntax looks 
very nice. I guess that `(constraint::not_null, 
constraint::default(false) ' builds a mpl::vector of types describing 
carrying the extra information ?

Matus Chochlik uses _ for defaults in Mirror (btw most of the 
TABLE.COLUMN machinery is inspired by Matus' work). The COLUMN macro 
could automatically fish from the constraints namespace :

    BOOST_RDB_BEGIN_TABLE(person)
      BOOST_RDB_COLUMN(id, integer, (primary_key))
      BOOST_RDB_COLUMN(name, varchar<20>, (not_null))
      BOOST_RDB_COLUMN(first_name, varchar<30>, _)
     BOOST_RDB_COLUMN(age, integer, _)
      BOOST_RDB_COLUMN(married, boolean, (not_null,default(false)))
    BOOST_RDB_END_TABLE(person)

Also we will need a way of forcing the C++ type to something else than 
the default (currently nested inside integer, varchar<>, etc). And also 
the column and table names (in case they conflict with C++ keywords).

Food for thought...

J-L