[Opensim-dev] nhibernate progress, baby steps

Fri Apr 4 14:10:15 UTC 2008

Well, its learning curve maybe is higher at the beginning than a
"propietary" solution based only on SQL because we won't think in SQL, we
are working with objects.

Some advantages of hibernate:
- Support for around 20 DDBB systems. Nowadays the opensim Data framework is
limited to 2 or 3 dbs and this framework had to be built from zero. What if
a big business wants to use Oracle for an Opensim Enterprise Hosting? From
my experience working in a "multinational" and having hundreds of big
clients (including banks, nuclear plants, governments...) I have never seen
mysql, sqlite or even prostgresql used as RDBMS (this doesn't mean they are
better or worst). This point (compatibility) is a good point to expand OS
project to enterprise world (where the money, support and donations are).
- Related with previous: why reinvent the wheel?
- Session management, transactions, triggers.... everything is managed from
hibernate. If one RDBMS hasn't, for example, transaction management, it
doesn't care, it's managed by hibernate (yes, there are limits, but in
general is "use me for everything and don't worry about your db").

And etc, etc etc.

About your worries:
- Configuration: there are several ways to configure hibernate. The examples
you have seen (from me or from Sean) are 2 ways to do it. And think, you
only need to know 2 things, the same to know if using a custom mapper: how
to connect to DB and how to store/recover the objects. the only thing is
different is the way to instruct the code with that info.
- Changes in object model are not needed. Always is possible to use
"passthrough" objects mapping current libsl structures to hibernate objects.
Scene objects work with libsl structs, isn't it? When they have to be
persisted, just send them for the passthrough, as nowadays is did (Data is a
passthrough, converts libsl structs into native SQL).
- Another option: uses the structs directly as hibernate objects. It's not
forbidden (not recommended, but not forbidden). You will save some
microseconds.
- Inter-table dependendencies are unneeded, if you want to maintain the
objects isolated, you can. The advantages of foreign keys are for db
integrity but if you want to maintain it in the core, do it.
- Granularity: this is a territory for a good DBA. In the beginning I
thought in the way of saving complete objects (avatar, containing
attachments, containing prims, containing script, etc etc). Working this way
I only needed 3 avies connected to a sim to note that the db overload was
higher and higher even doing anything. In this point I agree with you... but
hibernate allows to do it this way. It isn't mandatory to establish
relationships between objects.

One thing, I haven't any relationship with hibernate/nhibernate projects, I
am only a simple user (and till last year I really hated hibernate because I
didn't understand it).

Greetings

2008/4/4, Stefan Andersson <stefan at tribalmedia.se>:
>
> At this point I must, again, ask 'what is the point of nhibernate'?
>
> From just looking at the discussions, it seems
>
> * Overly complex (the configuration seem to, in themselves, be on par with
> actually coding generic mappers)
> * Mandating major changes in our object structure (opening up for
> encapsulation violations or forcing dependencies on hibernate)
> * Totally invasive (as in, in practice demanding its storage philosophy to
> be acommodated for and coded into core objects)
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> Best,
> /Stefan
>
>  ------------------------------
> Date: Fri, 4 Apr 2008 10:23:33 +0200
> From: impalah at gmail.com
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] nhibernate progress, baby steps
>
> Hello everyone:
>
> I hadn't any time to "nhibernating" opensim (as I told months ago) but the
> code I did is there.
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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...
>
> 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.
>
> Greetings and good luck
>
> Impalah "busy guy" Shenzhou
>
>
>
>
> 2008/4/3, Stefan Andersson <stefan at tribalmedia.se>:
>
> Yeah, well; I'm not saying it IS, just that we need to check on it.
>
> 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.
>
> /Stefan
>
>
> ------------------------------
>
> > Subject: RE: [Opensim-dev] nhibernate progress, baby steps
> > From: brianw at terrabox.com
> > To: stefan at tribalmedia.se
> > CC: opensim-dev at lists.berlios.de
> > Date: Thu, 3 Apr 2008 13:04:37 -0500
> >
> >
> > Ouch. That's not good.
> >
> >
> > On Thu, 2008-04-03 at 19:55 +0200, Stefan Andersson wrote:
> > > It seems the MySQL connector for .net assumes the db field is a
> > > string for its internal MySqlDataReader.GetGuid() implementation.
> > >
> > > (I could have been looking at source for an old revision of the
> > > connector, but that needs to be checked out anyway)
> > >
> > > So, that might mean that going binary could wreck stuff like
> > > nhibernate, if that's using a DataReader.
> > >
> > > Best,
> > > /Stefan
> > >
> > >
> > >
> > >
> > >
> > > ______________________________________________________________________
> > >
> > > > Date: Thu, 3 Apr 2008 13:49:03 -0400
> > > > From: sean at dague.net
> > > > To: brianw at terrabox.com; opensim-dev at lists.berlios.de
> > > > Subject: Re: [Opensim-dev] nhibernate progress, baby steps
> > > >
> > > > On Thu, Apr 03, 2008 at 11:19:58AM -0500, Brian Wolfe wrote:
> > > > > *nod* sounds good to me as well. I just have one request since
> > > we'll be
> > > > > changing things up at this level. Can we shoot for UUIDs being
> > > stored as
> > > > > a byte[16] in order to gain the 10x speedup in SQL
> > > indexing/storage vs
> > > > > string(32|36) ?
> > > >
> > > > That's definitely an option. It did however seem like there was some
> > > > speedup on LLUUID processing if we kept strings. I'm not sure where
> > > the
> > > > two end up colliding on speedup effects.
> > > >
> > > > -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
>
>
>
> _______________________________________________
> 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/20080404/1ed95179/attachment-0001.html>