jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Poce <edgarp...@gmail.com>
Subject Re: Chained Persistence and Filesystem
Date Fri, 04 Mar 2005 15:21:21 GMT

Stefan Guggisberg wrote:
> 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
> sounds interesting. do you mind sharing your design with us in a 
> few sentences?
figure 2.
Each concrete handler is a PersistenceManager wrapper and delegates the 
call only if certain condition is satisfied. Initially I thought of 
handlers that performs the evaluation based on the uri 
(UriPersistenceHandler), on the node type (NodeTypePersistenceHandler) 
and a DefaultPersistenceHandler which always delegates it.

>>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'm really confused now. Why level 1 and 2 are mutually excluded? I 
thought a level 2 repo should have at least all the features of the 
level 1.

If, as you said, I shouldn't chain persistence managers, if I had a few 
legacy systems I would need a jcr instance for each one?

And if I had a level 2 repo, it would be *only* a level 2 and I 
shouldn't integrate any other source?

I comment my use case. I'm working with a big amount of data, censuses 
and other household surveys. I'd like to store each survey with 
jackrabbit, but I'd like/need jackrabbit could share the data with any 
statistical processing engine because I don't feel like implementing 
statistical algorithms. That's why I need a custom orm pm for 
myapp:mysurvey nodetype. What's the best practice?

> 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


View raw message