[Opensim-dev] further db thoughts

[Nebadon Izumi]

Just a heads up there have been a few on the IRC  channel who can not
compile this with Mono 1.2.6 not a huge deal but i figured i would let you
know.

error looks like this:

http://www.pastebin.ca/854357

downgrading to Mono 1.2.5.1 seems to fix the problem.

Nebadon

On Jan 13, 2008 12:42 PM, Stefan Andersson < stefan at tribalmedia.se> wrote:

> 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.
> > __________________________________________________________________
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080114/26c8890b/attachment-0001.html>