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: bdb-persistence & db-persistence in contrib
Date Fri, 14 Oct 2005 14:44:08 GMT
hi tomislav,

On 10/14/05, Tomislav Randjic <tomislav.randjic@smartsol.co.yu> wrote:
> Hi to all,
>
> > i'd like to propose the following:
> > - move the bdb-persistence & db-persistence code from
> >   contrib to core
> > - change default configuration to use DerbyPersistenceManager
> >   (db-persistence) instead of filesystem-based
> > ObjectPersistenceManager
> > - remove CQFileSystem from project.xml and default configuration
>
> I agree completely. Not having any transactional pm in jackrabbit is
> something I miss the most now. Also, it would be nice to see db-pm
> implementation which does store blobs in database too, and has 'normal' db
> schema instead of serializing everything in one column. I believe default db
> pm need a little improvement as JCR can use RDBMS in a better way, and am
> ready to help if this makes any sense to you..

while i am personally sceptic regarding efficiency of fully normalized schema
vs very simple non-normalized schema you're very welcome to contribute
a db pm that uses a fully normalized schema and stores binary properties
in the db. i think that would be a very good complement to the current
SimpleDbPersistenceManager so people could use whatever they prefer.

one of the goals of SimpleDbPersistenceManager has been that there
should be no deployment steps required, i.e. that you don't need to
install/start a server or install a schema before you can use jackrabbit.

i am looking forward to compare both approaches on different backends :)
i guess the results will vary depending on the backend,  but we will see.


cheers
stefan

>
> I had problems testing JCR's MySQL db pm impl. With more than ~1000 child
> nodes on root node - MySQL blob is 64k and serailized child node data could
> not be written. Switching it to longblob fixed that problem, but I think
> this 'serailized' approach is not performance wise. As I could see, there is
> ORM pm in the works (btw, I don't see the point of it in case of JCR: JSR ->
> ORM -> RDBMS -- we need JSRRM :) but some sort schema like in ORM pm could
> be used for default DB pm. I think this could be much faster than present db
> pm impl.
>
> With blob properties on FS - I am aware that very large blobs are problem
> with some RDBMS. As I need some sort of repository for new DMS with
> potentially very large data, we are in process of testing slicing large data
> into multiple pages - blob columns in DB. I believe, it could preserve a lot
> of memory in typical Web based *MS scenario and yet keep everything in DB
> which is in my opinion better than DB/FS approach for many reasons.
>
>
> Cheers,
> Tomislav Randjic
>
>

Mime
View raw message