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.<br><br>Some advantages of hibernate:<br>- 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).<br>
- Related with previous: why reinvent the wheel?<br>- 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").<br>
<br>And etc, etc etc.<br><br>About your worries:<br>- 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.<br>
- 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).<br>
- Another option: uses the structs directly as hibernate objects. It's not forbidden (not recommended, but not forbidden). You will save some microseconds.<br>- 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.<br>
- 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.<br>
<br>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).<br><br>Greetings<br><br><br><div>
<span class="gmail_quote">2008/4/4, Stefan Andersson <<a href="mailto:stefan@tribalmedia.se">stefan@tribalmedia.se</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">




<div>At this point I must, again, ask 'what is the point of nhibernate'?<br>
 <br>