No subject


Sat Apr 19 02:14:48 UTC 2014


 <br>
* Overly complex (the configuration seem to, in themselves, be on par with actually coding generic mappers)<br>
* Mandating major changes in our object structure (opening up for encapsulation violations or forcing dependencies on hibernate)<br>
* Totally invasive (as in, in practice demanding its storage philosophy to be acommodated for and coded into core objects)<br>
 <br>
It has been proven a very bad thing to let objects take care of their own db serialization. More often than not, the object cannot be serialized from within its own context (it might not have data like 'parent' needed for relational storage) - and the object itself should not know about any given serialization method.<br>

 <br>
It IS a very bad thing to rely on 'storage' as a prime db serialization concept - you want 'changes': the first thing we need to do when we get to optimize the db layer, is to introduce more fine-grained update calls, like 'ChangeOwner' and 'StoreTextures' instead of 'store object, with prims, textures and shapes'. I have asked several times how this would be accomodated in nhibernate, but have got no answers.<br>

 <br>
Now, I've been asking for some kind of overview of the wins with this and what the drawbacks are, but have so far got none that gives me any idea of what impact this has on our modular approach or on performance.<br>

 <br>
If we're not going to let it 'hibernate' objects, as in 'let the objects themselves store themselves' and if we have to set up config files detailing out the mappings, why simply not just CODE the thing and get the granularity, performance and customizability (as in, being able to let the objects be serialized according to their different internal structures) that comes with it?<br>

 <br>
Best,<br>
/Stefan<br><br>
<blockquote>
<hr>
Date: Fri, 4 Apr 2008 10:23:33 +0200<br>From: <a href="mailto:impalah at gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">impalah at gmail.com</a><br>To: <a href="mailto:opensim-dev at lists.berlios.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">opensim-dev at lists.berlios.de</a><div>
<span class="e" id="q_1191990fa115c1b2_1"><br>Subject: Re: [Opensim-dev] nhibernate progress, baby steps<br><br>Hello everyone:<br><br>I hadn't any time to "nhibernating" opensim (as I told months ago) but the code I did is there.<br>
<br>Sean I know my code may be "complicated" when starting, that's for the use of factories and DAO's. My intention was to convert every nhibernate object in a DAO, so they will know how to save, update, delete... themselves (a simple call to AssetDAO.Save(id) for example). Well, for testing your approach is better if you don't have enough experience with hibernate.<br>
<br>Second, my approach was to not modify the current objects, mapping them to nhibernate classes. Of course the better idea is to use the libsl-hibernatized objects (with getters and setters) throughout the code w/o intermediate mapping classes. I think the advantages of having "intelligent" getters and setters where we could put validations, or even classes than can serialize (to XML or whatever) are more than the "overload and memory use" disadvantages.<br>
<br>Third (fuck, I'm making a list) the ID question: do not use the "auto" ids (generated by nhibernate). Let opensim create them. The overhead of letting hibernate create these ids is higher than the CoCreateId call opensim does. If you want to use a byte array for storing ids (due to better performance), use it; hibernate hasn't any problem with it (the "recommended id" is an integer because hibernate is often used in "enterprise environments", there isn't any other reason).<br>
<br>Four, I tested my previous code (apart from .NET) with mono + SQLite + nhibernate w/o "touching" anything (I used the included sqlite drivers included with opensim). I can't help you here.<br><br>Five, instead of using the hbm.xml files you can use mapping attributes (that was the point where I stopped). The same with the hibernate.cfg.xml, you can set its properties "programatically". The advantages: if you change one data object you don't have to change the xml file too; and less files in the bin directory as well.<br>
<br>Six, you can generate the db schemma automatically (I think I provided an example), it's db independent. If you are using mapping attributes instead of hbm.xml just serialize the objects (there are some examples looking for "nhibernate mapping attributes" in google). It works...<br>
<br>Seven, sorry. I wanted to help you developing a hibernate base but I had only 1 "relatively" free week to did it. Maybe in the future.<br><br>Greetings and good luck<br><br>Impalah "busy guy" Shenzhou<br>
<br><br><br><br>
<div><span>2008/4/3, Stefan Andersson <<a href="mailto:stefan at tribalmedia.se" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">stefan at tribalmedia.se</a>>:</span> 
<blockquote style="padding-left: 1ex;">
<div>Yeah, well; I'm not saying it IS, just that we need to check on it.<br><br>I glimpsed that as I was trying to find out what the 'best practice' for storing guids in MySQL databases was; I actually didn't find any good info on that.<br>
 <br>/Stefan<br><br><br>
<hr>
<br>> Subject: RE: [Opensim-dev] nhibernate progress, baby steps<br>> From: <a href="mailto:brianw at terrabox.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">brianw at terrabox.com</a><br>> To: <a href="mailto:stefan at tribalmedia.se" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">stefan at tribalmedia.se</a><br>
> CC: <a href="mailto:opensim-dev at lists.berlios.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">opensim-dev at lists.berlios.de</a><br>> Date: Thu, 3 Apr 2008 13:04:37 -0500 
<div><span><br>> <br>> <br>> Ouch. That's not good. <br>> <br>> <br>> On Thu, 2008-04-03 at 19:55 +0200, Stefan Andersson wrote:<br>> > It seems the MySQL connector for .net assumes the db field is a<br>
> > string for its internal MySqlDataReader.GetGuid() implementation.<br>> > <br>> > (I could have been looking at source for an old revision of the<br>> > connector, but that needs to be checked out anyway)<br>
> > <br>> > So, that might mean that going binary could wreck stuff like<br>> > nhibernate, if that's using a DataReader.<br>> > <br>> > Best,<br>> > /Stefan<br>> > <br>> > <br>
> > <br>> > <br>> > <br>> > ______________________________________________________________________<br>> > <br>> > > Date: Thu, 3 Apr 2008 13:49:03 -0400<br>> > > From: <a href="mailto:sean at dague.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">sean at dague.net</a><br>
> > > To: <a href="mailto:brianw at terrabox.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">brianw at terrabox.com</a>; <a href="mailto:opensim-dev at lists.berlios.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">opensim-dev at lists.berlios.de</a><br>
> > > Subject: Re: [Opensim-dev] nhibernate progress, baby steps<br>> > > <br>> > > On Thu, Apr 03, 2008 at 11:19:58AM -0500, Brian Wolfe wrote:<br>> > > > *nod* sounds good to me as well. I just have one request since<br>
> > we'll be<br>> > > > changing things up at this level. Can we shoot for UUIDs being<br>> > stored as<br>> > > > a byte[16] in order to gain the 10x speedup in SQL<br>> > indexing/storage vs<br>
> > > > string(32|36) ?<br>> > > <br>> > > That's definitely an option. It did however seem like there was some<br>> > > speedup on LLUUID processing if we kept strings. I'm not sure where<br>
> > the<br>> > > two end up colliding on speedup effects.<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" onclick="return top.js.OpenExtLink(window,event,this)">http://dague.net</a> <a href="http://mhvlug.org/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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>> <br><br></span></div></div><br>_______________________________________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev at lists.berlios.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Opensim-dev at lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br><br></blockquote></div><br>
</span></div></blockquote></div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berlios.de</a><br>
<a onclick="return top.js.OpenExtLink(window,event,this)" 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>

------=_Part_6417_11978504.1207318215374--



More information about the Opensim-dev mailing list