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