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.