Re: [boost] Interest from BoostCon

From: Preston A. Elder (prez_at_[hidden])
Date: 2007-05-30 18:03:48

Maybe you can include me in on your conversations :)

The end goal I am working towards is more something that works on 3 layers.
The first layer is where you are more or less dealing with more low level
stuff, more or less what I have now, where I can retrieve rows (which may
be only a subset of all fields), insert, update, delete, etc.  I want to
expand it to handle cross-table stuff and views and more 'common' things
(like max(), min(), count(), etc).  But still dealing with more a less a
vector of maps (vector enabling multi-row stuff and the map for key/value
pairs).  I'm using boost::variant for data items, and I find this very
useful, but I want to be able to expand that to user-defined types.

At this low level I also want to add stuff in to be able to identify what
is supported natively by the backend (one thing I do this currently with
is 'defaulted' fields for an insert where you can skip certain fields and
the default value is taken - SQL supports this, others don't and I allow
you to provide a function to provide the default value).

The next layer I want to add transactional and cursor semantics - the
ability to group subsequent operations.  This means I will have to WRITE
such things for databases that don't support it.

The top layer is more what you are doing here, mapping an object to
underlying storage.  This can be done either via. 'loose' coupling (where
we load an object and save it on destruction via. some smart pointer or
something) or 'tight' coupling (individual fields are tied directly, and
modifications can affect the database immediately).  Either would also
require some kind of cache more than likely.

Obviously there is SOME interest in this :)
I plan on doing something like this anyway, and possibly submitting it to
Boost - would be a shame to duplicate effort :)

The three bug reports explain the above in even more detail:
http://www.neuromancy.net/mantra/trac/ticket/1
http://www.neuromancy.net/mantra/trac/ticket/2
http://www.neuromancy.net/mantra/trac/ticket/3

Using Proto would be a good idea for layer 3, I'm not sure how much use it
can be for Layers 1 and 2 :)

On Wed, 30 May 2007 15:15:28 -0500, Rene Rivera wrote:

> Hm, interesting, I'll have to read through this a bit more because... As 
> a result of some conversations, and some of the sessions, at BoostCon 
> John and I started designing a schema definition and general database 
> interfacing library. This is one area where we have considerable 
> experience and some, IMO, interesting ideas. Here's part of a short 
> example of what we are considering:
> 
> template <typename C>
> struct Person
>      : rsi::db::schema::table_def< C, Person<C> >
> {
>      column id;
>      column first_name;
>      column last_name;
>      column address;
>      column mail_address;
>      column phone;
> 
>      template <typename T>
>      typename T::result_type operator()(T const & transform)
>      {
>          return transform(
>              table("Person")
>                  <<= id("id")
>                      % integer[autoincrement]
>                      & not_null & primary_key
> 
>                  <<= first_name("first_name")
>                      % character(50)[varying]
>                      & not_null
> 
>                  <<= last_name("last_name")
>                      % character(50)[varying]
>                      & not_null
> 
>                  <<= address("address_id")
>                      >> Address<C>().id
> 
>                  <<= mail_address("mail_address_id")
>                      >> Address<C>().id
> 
>                  <<= phone("phone")
>                      % character(20)[varying]
>                      & not_null
>              );
>      }
> };
> 
> Obviously we'll be basing it on Eric's Proto library. The goal is to 
> have separate the various database declarations from the database 
> operations. This would be in the same style of separating containers and 
> algorithms in the STL.
> 
>