Re: [boost] Interest from BoostCon

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-05-30 16:15:28

Preston A. Elder wrote:
> - Generic Data Storage Backend:
> http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/storage
> and
> http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/storage
> 
> This allows you to have a common interface to your storage back end,
> regardless of whether its an SQL database, Berkeley DB, XML file, etc.  It
> also allows you to CODE a query, eg:
> 	Condition<C_LessThan>("col1", 3") &&
> 		(Condition<C_EqualTo>("col2", "hello") ||
> 		 Condition<C_EqualTo>("col2", "world")) &&
> 	Condition<C_Masked>("col3", FLAG_A | FLAG_B)
> 
> This will then expand to an SQL expression for SQL DB's, or apply to data
> rows for non-SQL DB's - ie. it will work for all data sources.
> 
> Right now I plan on re-writing this anyway to support:
> * Cross-table/database queries, better column limits and more operations:
> (http://www.neuromancy.net/mantra/trac/ticket/1)
> * Transactions & Cursors (http://www.neuromancy.net/mantra/trac/ticket/2)
> * An Object-based model (http://www.neuromancy.net/mantra/trac/ticket/3)
> 
> But I would like to know if there is interest for this in the boost
> community or more specifically, in turning it into a boost module in its
> own right.

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.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo