But if I want to run the JDBC PM on a number of different database (Oracle, Ingres, MSSQL) I will need a number of different schemas, will I not ?
-----Original Message----- From: Serge Huber [mailto:[EMAIL PROTECTED] Sent: 10 June 2005 15:11 To: [email protected] Subject: Re: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by edgarpoce Edgar has already done just that, see : http://issues.apache.org/jira/browse/JCR-91 cheers, Serge... Simon Gash wrote: >Stefan, > >I'm still trying to grasp some of the concepts here, are you saying >it's the ORM mapping layer that's the overhead here. Hence it would be >better to design a simple schema (if that's possible) and avoid all the >mapping stuff that comes with Hibernate or JDO stuff ? > >Thanks >Simon > >-----Original Message----- >From: Stefan Guggisberg [mailto:[EMAIL PROTECTED] >Sent: 09 June 2005 14:24 >To: [email protected] >Subject: Re: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by >edgarpoce > >On 6/9/05, Serge Huber <[EMAIL PROTECTED]> wrote: > > >>Stefan Guggisberg wrote: >> >> >> >>>me too sorry to be so pedantic ;) the role of the PM in jackrabbit >>>(at least as i originally designed it) is comparable to the role of >>>that layer in a rdbms that reads and writes raw table/record data >>>to/from the disk (e.g. tablespace files in oracle). you wouldn't >>>expect oracle to store the raw table/record data in ORM instead of >>> >>> >its tablespace files i guess. > > >>>btw, edgar's PM FAQ quite nicely explains the role of the PM in >>> >>> >jackrabbit. > > >>> >>> >>The problem as I see it is that RDBMS handle also all the transaction, >> >> > > > >>clustering, caching, replication, backup etc. This makes for a lot of >>complexity. If we do the same in Jackrabbit this means that we will be >> >> > > > >>reproducing a lot of what lower storage systems (like JDBC) can >>already do no ? >> >> > >i am not saying that jackrabbit should provide implementations of such >services on the persistence layer. a lot of powerfull yet simple >storage systems can provide this kind of functionality without >introducing a lot of overhead. take for example berkeley db or mysql. >on the other hand i don't believe that using an object relational db >would gain any benefits but only introduce a lot of unnecessary >complexity. you can easily (and >efficiently;) persist jackrabbit's data (NodeState, PropertyState & >NodeReferences objects) in a primitive schema with three 2-column >tables and still benefit from transactions, etc. provided by your >storage system. > >cheers >stefan > > > > > >>Just trying to understand :) >> >>cheers, >> Serge... >> >> >> > >Come visit us at: > >Internet World 2005. June 14 - 16, Earls Court, Stand # A60 > >Government Computing Expo. June 21 & 22, Earls Court, Stand # 804 > >SOCITM Annual Event. October 16 - 18 Brighton Hotel, Stand # 28 GOSS - >Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in the Deloitte Technology Fast 500 EMEA. > >This email contains proprietary information, some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you may not use, disclose, distribute, copy, print or rely on this email. > > > >Email transmission cannot be guaranteed to be secure or error free, as information may be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. This email and any files attached to it have been checked with virus detection software before transmission. You should nonetheless carry out your own virus check before opening any attachment. GOSS Interactive Ltd accepts no liability for any loss or damage that may be caused by software viruses. > > > > > Come visit us at: Internet World 2005. June 14 - 16, Earls Court, Stand # A60 Government Computing Expo. June 21 & 22, Earls Court, Stand # 804 SOCITM Annual Event. October 16 - 18 Brighton Hotel, Stand # 28 GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in the Deloitte Technology Fast 500 EMEA. This email contains proprietary information, some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you may not use, disclose, distribute, copy, print or rely on this email. Email transmission cannot be guaranteed to be secure or error free, as information may be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. This email and any files attached to it have been checked with virus detection software before transmission. You should nonetheless carry out your own virus check before opening any attachment. GOSS Interactive Ltd accepts no liability for any loss or damage that may be caused by software viruses.
