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.<br><br>error looks like this:<br><br><a href="http://www.pastebin.ca/854357">

http://www.pastebin.ca/854357</a><br><br>downgrading to Mono <a href="http://1.2.5.1">1.2.5.1</a> seems to fix the problem.<br><br>Nebadon<br><br><div class="gmail_quote">On Jan 13, 2008 12:42 PM, Stefan Andersson <

<a href="mailto:stefan@tribalmedia.se" target="_blank">stefan@tribalmedia.se</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>Ok, I just committed /OpenSim/ThirdParty/Tribal/TribalMedia.Framework.Data<br>

 <br>

This should be specialized into OpenSim.Framework.Data, which should do the following:<br>

* Specialize the FieldMapper <font size="2">ExpandField, <font size="2">GetValue and <font size="2">ConvertToDbType to accomodate LLVector3, LLQuaternion and LLUUID</font></font></font><br>

<font size="2"><font size="2"><font size="2">* 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)</font>

</font></font><br>

<font size="2"><font size="2"><font size="2">* DatabaseProviders for all supported database engines, ie OpenSim.Framework.Data.MySQL should subclass and extend the DatabaseMapper</font></font></font><br>

 <br>

<font size="2"><font size="2"><font size="2">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.<br></font></font>

 <br>

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

 <br>

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

 <br>

Eagerly awaiting peer review and comments,<br>

/Stefan<br>

</font><br> <br>

<hr>

<br>

> Date: Sat, 12 Jan 2008 09:39:20 -0500<div><br>> From: <a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a><br>> To: <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de

</a><br></div>> Subject: Re: [Opensim-dev] further db thoughts<div><div></div><div><br>> <br>> On Fri, Jan 11, 2008 at 09:46:21PM +0100, Stefan Andersson wrote:<br>> > Sean,<br>> > <br>

> > 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:<br>> > <br>> > * I have a DbConnectionPool that acts as a programmatic manager of connections (Subclassed into MySqlDbConnectionPool)

<br>> > * 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)

<br>> > * 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.

<br>> > * 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.

<br>> > <br>> > 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.<br>> > <br>> > If this sounds like something we'd want, I'd be happy to make it

<br>> > available as a third-party BSD Licence lib within the project, my only<br>> > demand is that it is called TribalMedia.Framework.Data and that the<br>> > BSD header remains intact.<br>> <br>> I think it is definitely a promissing approach. If you wanted to check

<br>> it in under TribalMedia/Framework/Data I'll definitely check it out. If<br>> it turns out to not work out, we can just remove it down the road.<br>> <br>> -Sean<br>> <br>> -- <br>> __________________________________________________________________

<br>> <br>> Sean Dague Mid-Hudson Valley<br>> sean at dague dot net Linux Users Group<br>> <a href="http://dague.net" target="_blank">http://dague.net</a> <a href="http://mhvlug.org" target="_blank">http://mhvlug.org

</a><br>> <br>> There is no silver bullet. Plus, werewolves make better neighbors<br>> than zombies, and they tend to keep the vampire population down.<br>> __________________________________________________________________

<br><br></div></div></div>

<br>_______________________________________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">

https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br><br></blockquote></div><br>