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 16:15:48 GMT

Jukka Zitting wrote:
> Hi,
> Edgard Poce wrote:
>>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?
> There are few best practices yet, but in my opinion you'd better focus
> on doing the integration on top of the JCR API, not below it. Is it
> possible to implement a JCR storage adapter for the statistical
> processing engine you are using? Or alternatively implement an export
> feature that extracts the required data from a JCR content repository.
i think that exporting a 1gb database database is not an option. Besides 
I should write the code to perform the conversion from jcr api to a 
readable db format, I guess it's not so hard but there's no need to do it.

> You can think of the Jackrabbit persistence manager layer as the storage
> layer of an RDBMS implementation. The JCR API is to Jackrabbit what JDBC
> is to an RDBMS. You can use a database to store your data and integrate
> it with your applications using the public API, but you certainly
> wouldn't want to try making your externally stored data visible inside
> the database by writing a custom storage layer implementation... ;-)
I don't fully understand what you said. :(
I want to store, edit, browse, data through the jcr api, and make the 
statistical processing directly from the persistence storage. It would 
be just a read only task, so it shouldn't affect the jackrabbit normal 

I'm far (really far) from being a db expert, and I still don't get the 
big picture of jackrabbit internals, but I think jackrabbit is unable, 
and probably will allways be, to perform aggregated queries as fast as 
any of the os or commercial dbs.

> BR,
> Jukka Zitting

View raw message