<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Uhh. *scratches head*<BR>
<BR>It seems mono has a problem creating the anonymous delegate method... but that's nothing unique for this code; could you mono people please check to see if this is a known bug, because if it's general behaviour, it's a BIG bug.<BR>
<BR>
(Oddly, we use this construct all over the place in the rest of the code, so I don't see why this should be a problem)<BR>
<BR>
Best,<BR>
/Stefan<BR><BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
Date: Mon, 14 Jan 2008 00:14:40 -0700<BR>From: nebadon2025@gmail.com<BR>To: opensim-dev@lists.berlios.de<BR>Subject: Re: [Opensim-dev] further db thoughts<BR><BR>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" target=_blank>http://www.pastebin.ca/854357</A><BR><BR>downgrading to Mono <A href="http://1.2.5.1/" target=_blank>1.2.5.1</A> seems to fix the problem.<BR><BR>Nebadon<BR><BR>
<DIV class=EC_gmail_quote>On Jan 13, 2008 12:42 PM, Stefan Andersson < <A href="mailto:stefan@tribalmedia.se">stefan@tribalmedia.se</A>> wrote:<BR>
<BLOCKQUOTE class=EC_gmail_quote style="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">sean@dague.net</A><BR>> To: <A href="mailto:opensim-dev@lists.berlios.de">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' <BR>> > * A 'Schema' is a collection of FieldMapper<T><BR>> > * 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. <BR>> > * 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.<BR>> > <BR>> > - 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. <BR>> > <BR>> > 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">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></BLOCKQUOTE></body>
</html>