jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Chained Persistence and Filesystem
Date Fri, 04 Mar 2005 14:00:39 GMT
hi edgar,

On Wed, 02 Mar 2005 14:40:12 -0300, Edgar Poce <edgarpoce@gmail.com> wrote:
> Hi to all
> I need to store data with many persistence managers, ORMPersistence for
> some custom node types, XMLPersistence in mem for temp data and
> XMlPersistence on disk for the rest.
> I'm planning to make a ChainedPersistence and a ChainedFileSystem
> manager, both implementing the chain of responsibility pattern.
> The general idea is to wrap the PersistenceManager in a persistence
> handler which delegates the call if a certain condition is satisfied.
> Initially, I would need a UriPersistenceHandler and a
> NodeTypePersistenceHandler.

sounds interesting. do you mind sharing your design with us in a 
few sentences?

> Is there any plan to include this feature in the short term? Is it a
> good approach?

i am bit worried about doing fancy stuff in PersistenceManagers 
in general. let me explain...

the PersistenceManager interface was never intended as being
a general SPI that you could implement in order to integrate 
external datasources with proprietary formats (e.g. a customers 

the reason why we abstracted the PersistenceManager interface
was to leave room for future performance optimizations that 
would not affect the rest of the implementation (e.g. by storing 
the raw data in a b-tree based database instead of individual file).

the PersistenceManager sits at the very bottom layer in
jackrabbits (not yet existing... :(  system architecture diagram.
reliability, integrity and performance of the PersistenceManager
are *crucial* to the overall stability & performance of the repository.
if e.g. the data that a PersistenceManager is based upon is 
allowed to change through external means the integrity
of the repository would be at risk (think of referential integrity/
node references e.g.).

therefore, imo, a PersistenceManager  should not be 'intelligent', 
it should not 'interpret' the data. the only thing it should care about 
is to efficiently, consistently and reliably store and read the data 
encapsulated in the passed NodeState & PropertyState objects.

though it might be feasible to write a custom persistence manager
to represent existing legacy data in a level-1 (read-only) repository,
i don't think the same is possible for a level-2 repository and i 
certainly would not recommend it.

i hope i didn't scare you off, i just wanted to make sure that you are
fully aware of all potential risk & implications when writing 
custom persistence managers.


> Any feedback is welcome.
> thanks for your support
> edgar

View raw message