[Opensim-dev] further db thoughts

Sun Jan 13 19:42:54 UTC 2008

Ok, I just committed /OpenSim/ThirdParty/Tribal/TribalMedia.Framework.Data

This should be specialized into OpenSim.Framework.Data, which should do the following:
* Specialize the FieldMapper ExpandField, GetValue and ConvertToDbType to accomodate LLVector3, LLQuaternion and LLUUID
* Provide a set of TableMappers for all supported object types (I will try to commit primitivebaseshape, part and group soonish, but I'm a bit pressed for time at the mo)
* DatabaseProviders for all supported database engines, ie OpenSim.Framework.Data.MySQL should subclass and extend the DatabaseMapper

Alas, the code as it is committed five minutes ago, is kinda forcefully ripped out of its context, but I guess it's a work in progress.

(For example, the DatabaseMapper is both connectionpool and querybuilder, which might not be ideal.)

Ideally, basing our db layer on something like this should mean we never again should get out of synch on this or that database.

Eagerly awaiting peer review and comments,
/Stefan

> Date: Sat, 12 Jan 2008 09:39:20 -0500> From: sean at dague.net> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] further db thoughts> > On Fri, Jan 11, 2008 at 09:46:21PM +0100, Stefan Andersson wrote:> > Sean,> > > > I know you're going to hate me for this, but before I post code, I just wanted to explain whats here 'on my own hard-disk' to see if it's anything like what you want to do:> > > > * I have a DbConnectionPool that acts as a programmatic manager of connections (Subclassed into MySqlDbConnectionPool)> > * this is passed to a TableMapper which exposes it as a protected method WithConnection(delegate) for subclasses to access; they never access the connectionpool directly; the delegate approach lets the TableMapper lock, allocate, pre- and postprocess the connection securely and encapsulated. (kind of like a using clause)> > * The TableMapper is subclassed into a TableMapper<TRowMapper> that implements a CRUD interface by creating dynamic sql queries (the param prefix is pulled from the ConnectionPool) and populating them from a 'Schema'> > * A 'Schema' is a collection of FieldMapper<T>> > * FieldMapper<TField> is initialized with a field/param name (same for laziness sake), TField is the RowMapper field value type, a get delegate and a set delegate for the TField type object. It also does all the db/field type casting as well as expands things like Vector and Quaternion into several db fields.> > * The delegate approach keeps everything field related together, as opposed to a FromReader/ToReader method approach, which helps dodge inconsistencies.* The TRowMapper is mostly of type RowMapper<TRowObject> which just creates a class that has a member of TRowObject; this lets you subclass TRowMapper<TRowObject> and add db-specific extra-fields to it in order to manage hierarchies.> > * Upon operations, you create your rowmapper object (or just a plain object if there is no aux data) and either do FillObject( Schema, rowObject) or extract stuff by overrifing the FromReader(rowObject, DbReader) - the latter I use to populate a group from a part table (the select on the key field returns multiple rows, so i just PartMapper.FromReader() on each one to build the group.> > > > - it does NOT auto-create tables, as I'm not interested in that approach as you know, but you already have the code for it and the data in the 'Schema' so it should be a piece of pie.> > > > All in all, everything is explicit and compile-time; no cacheing, synchronization or double-buffering, no reflected and emitted code, but it works, and is quite efficient. It takes a while to get into the flow of how the various components work together, but after that I feel it's very conveniens and trustworthy.> > > > Of course, it needs more work to get it going on all different database interfaces, but it's created from the start to be subclassed into differing databases.> > > > If this sounds like something we'd want, I'd be happy to make it> > available as a third-party BSD Licence lib within the project, my only> > demand is that it is called TribalMedia.Framework.Data and that the> > BSD header remains intact.> > I think it is definitely a promissing approach. If you wanted to check> it in under TribalMedia/Framework/Data I'll definitely check it out. If> it turns out to not work out, we can just remove it down the road.> > -Sean> > -- > __________________________________________________________________> > Sean Dague Mid-Hudson Valley> sean at dague dot net Linux Users Group> http://dague.net http://mhvlug.org> > There is no silver bullet. Plus, werewolves make better neighbors> than zombies, and they tend to keep the vampire population down.> __________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080113/fa53c661/attachment-0001.html>