[Opensim-dev] nhibernate progress, baby steps

[Brian Wolfe]

On Fri, 2008-04-04 at 16:10 +0200, Impalah wrote:
> 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.

SQLMapper leaves the SQL generation up to the individual SQL drivers
within it. I'm not terribly happy with the complex condition construct
that I came up with. 8-( WIth a bit more work from alternatively
thinking minds it could be made to be quite usefull as a generic
lightweight mapper.

> 
> 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).

>From what I have worked with so far, adding an SQL flavor to SQLMapper
is fairly simple 2 to 4 hours of work as it stands now.

> - Related with previous: why reinvent the wheel?

Because some wheels have everythign and the kitchen sink, which we
really dont' need IMHO in OpenSim.

> - 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").

I don't see any need for sessions in OpenSim. Maybe a few use examples
would be usefull here.

> 
> And etc, etc etc.

fluf, fluf, fluf.... ;)

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

A multitude of configurations is somethign that we're already dealing
with rather badly. ;-P

> - 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).

Sounds more like an argument that nhibernate gains us nothign here to be
blunt.

> - Another option: uses the structs directly as hibernate objects. It's
> not forbidden (not recommended, but not forbidden). You will save some
> microseconds.

SQLMapper can use anything we code it to use. ;)

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

Most systems like NHibernate dont' like having other things manage their
relationships. Course as you said, nhibernate can have something else do
it, but is it ging to be supported in the future?

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

I'm not really clear here what you are talking about. 8-( Maybe a bit
more detail or explaining it a different way?

> 
> 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).

Same here when I started with systems like NHibernate several years
ago. :)  It can be a really nice tool. However we need to carefully
weigh the risks vs rewards before picking a layer that goes past the
I*Data objects in the Data class.

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

Agreed.

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

Definitely agreed. However this will require a bit more complex objects
that can track changes made and update just those changes. Doctrine does
this in a wonderful way by maintaining 2 value tables internally. 1 that
is filled on create/read, and a second that is filled as values change.
This does impose a slight overhead during use where it has to check for
existance in the change table, then the original table before returning
a value. It could get ugly in RL use.

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

IMHO so far it's a wash between benifits and drawbacks. 8-/

>          
>         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
<SNIP SNIP SNIP>
>