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 encapsula=
tion 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 d=
b serialization. More often than not, the object cannot be serialized from =
within its own context (it might not have data like 'parent' needed for rel=
ational storage) - and the object itself should not know about any given se=
rialization method.<BR>
 <BR>
It IS a very bad thing to rely on 'storage' as a prime db serialization con=
cept - 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 call=
s, like 'ChangeOwner' and 'StoreTextures' instead of 'store object, with pr=
ims, textures and shapes'. I have asked several times how this would be acc=
omodated 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 w=
hat the drawbacks are, but have so far got none that gives me any idea of w=
hat 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 th=
emselves 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 granu=
larity, 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 id=3DEC_stopSpelling>
Date: Fri, 4 Apr 2008 10:23:33 +0200<BR>From: impalah at gmail.com<BR>To: open=
sim-dev at lists.berlios.de<BR>Subject: Re: [Opensim-dev] nhibernate progress,=
 baby steps<BR><BR>Hello everyone:<BR><BR>I hadn't any time to "nhibernatin=
g" 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 fa=
ctories 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 nhiberna=
te classes. Of course the better idea is to use the libsl-hibernatized obje=
cts (with getters and setters) throughout the code w/o intermediate mapping=
 classes. I think the advantages of having "intelligent" getters and setter=
s where we could put validations, or even classes than can serialize (to XM=
L or whatever) are more than the "overload and memory use" disadvantages.<B=
R><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 l=
etting hibernate create these ids is higher than the CoCreateId call opensi=
m does. If you want to use a byte array for storing ids (due to better perf=
ormance), 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 (a=
part from .NET) with mono + SQLite + nhibernate w/o "touching" anything (I =
used the included sqlite drivers included with opensim). I can't help you h=
ere.<BR><BR>Five, instead of using the hbm.xml files you can use mapping at=
tributes (that was the point where I stopped). The same with the hibernate.=
cfg.xml, you can set its properties "programatically". The advantages: if y=
ou change one data object you don't have to change the xml file too; and le=
ss 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 develop=
ing a hibernate base but I had only 1 "relatively" free week to did it. May=
be in the future.<BR><BR>Greetings and good luck<BR><BR>Impalah "busy guy" =
Shenzhou<BR><BR><BR><BR><BR>
<DIV><SPAN class=3DEC_gmail_quote>2008/4/3, Stefan Andersson <<A href=3D=
"mailto:stefan at tribalmedia.se">stefan at tribalmedia.se</A>>:</SPAN>=20
<BLOCKQUOTE class=3DEC_gmail_quote style=3D"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' f=
or storing guids in MySQL databases was; I actually didn't find any good in=
fo on that.<BR> <BR>/Stefan<BR><BR><BR>
<HR>
<BR>> Subject: RE: [Opensim-dev] nhibernate progress, baby steps<BR>>=
 From: <A href=3D"mailto:brianw at terrabox.com">brianw at terrabox.com</A><BR>&g=
t; To: <A href=3D"mailto:stefan at tribalmedia.se">stefan at tribalmedia.se</A><B=
R>> CC: <A href=3D"mailto:opensim-dev at lists.berlios.de">opensim-dev at list=
s.berlios.de</A><BR>> Date: Thu, 3 Apr 2008 13:04:37 -0500=20
<DIV><SPAN class=3DEC_e id=3DEC_q_119157af9feec1a2_1><BR>> <BR>> <BR>=
> Ouch. That's not good. <BR>> <BR>> <BR>> On Thu, 2008-04-03 a=
t 19:55 +0200, Stefan Andersson wrote:<BR>> > It seems the MySQL conn=
ector for .net assumes the db field is a<BR>> > string for its intern=
al MySqlDataReader.GetGuid() implementation.<BR>> > <BR>> > (I =
could have been looking at source for an old revision of the<BR>> > c=
onnector, but that needs to be checked out anyway)<BR>> > <BR>> &g=
t; So, that might mean that going binary could wreck stuff like<BR>> &gt=
; nhibernate, if that's using a DataReader.<BR>> > <BR>> > Best=
,<BR>> > /Stefan<BR>> > <BR>> > <BR>> > <BR>> &g=
t; <BR>> > <BR>> > ____________________________________________=
__________________________<BR>> > <BR>> > > Date: Thu, 3 Apr=
 2008 13:49:03 -0400<BR>> > > From: <A href=3D"mailto:sean at dague.n=
et">sean at dague.net</A><BR>> > > To: <A href=3D"mailto:brianw at terra=
box.com">brianw at terrabox.com</A>; <A href=3D"mailto:opensim-dev at lists.berli=
os.de">opensim-dev at lists.berlios.de</A><BR>> > > Subject: Re: [Ope=
nsim-dev] nhibernate progress, baby steps<BR>> > > <BR>> > &=
gt; On Thu, Apr 03, 2008 at 11:19:58AM -0500, Brian Wolfe wrote:<BR>> &g=
t; > > *nod* sounds good to me as well. I just have one request since=
<BR>> > we'll be<BR>> > > > changing things up at this le=
vel. Can we shoot for UUIDs being<BR>> > stored as<BR>> > > =
> a byte[16] in order to gain the 10x speedup in SQL<BR>> > indexi=
ng/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>> &gt=
; > <BR>> > > -- <BR>> > > ___________________________=
_______________________________________<BR>> > > <BR>> > &gt=
; Sean Dague Mid-Hudson Valley<BR>> > > sean at dague dot net Linu=
x Users Group<BR>> > > <A href=3D"http://dague.net/" target=3D_bla=
nk>http://dague.net</A> <A href=3D"http://mhvlug.org/" target=3D_blank>http=
://mhvlug.org</A><BR>> > > <BR>> > > There is no silver b=
ullet. Plus, werewolves make better neighbors<BR>> > > than zombie=
s, and they tend to keep the vampire population down.<BR>> > > ___=
_______________________________________________________________<BR>> &gt=
; <BR>> <BR><BR></SPAN></DIV></DIV><BR>_________________________________=
______________<BR>Opensim-dev mailing list<BR><A href=3D"mailto:Opensim-dev=
@lists.berlios.de">Opensim-dev at lists.berlios.de</A><BR><A href=3D"https://l=
ists.berlios.de/mailman/listinfo/opensim-dev" target=3D_blank>https://lists=
.berlios.de/mailman/listinfo/opensim-dev</A><BR><BR></BLOCKQUOTE></DIV><BR>=
</BLOCKQUOTE></body>
</html>=

--_3e0aae69-b7da-4b90-ae8a-20bc57d06fce_--



More information about the Opensim-dev mailing list