Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk