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
database).
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.
cheers
stefan
>
> Any feedback is welcome.
>
> thanks for your support
> edgar
>
>
|