You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Stefan Guggisberg <st...@gmail.com> on 2005/10/14 15:18:58 UTC
bdb-persistence & db-persistence in contrib
folks!
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
reasons for doing so would IMO be:
- there are currently only filesystem-based PMs available in core
- there is currently no PM in core supporting transactions
- we could leverage Derby, a sister apache project, as default
transactional persistence layer for jackrabbit
- we can get rid of CQFileSystem which is non-transactional,
non-opensource and not free for commercial use
what do you think?
cheers
stefan
Re: bdb-persistence & db-persistence in contrib
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Oct 24, 2005, at 8:07 AM, Stefan Guggisberg wrote:
> i moved the code in contrib/db-persistence to core, made
> DerbyPersistenceManager the "default' pm and removed
> CQFileSystem references (r328071).
Great!
> however, i did not yet move contrib/bdb-persistence to core.
> i realized that this would require adding a berkleydb dependency
> to jackrabbit-core. i didn't know if this would be ok.
It would only be okay as an optional (default off) dependency
in which the user could install their own jar, perhaps by setting
an additional property in maven.
> the most recent
> version of "BerkeleyDB Java Edition" available on
> http://www.ibiblio.org/maven
> is 1.7.1. the corresponding license can be found here:
> http://www.ibiblio.org/maven/berkeleydb/licenses/je-1.7.1.license
>
> IANAL but the license is certainly not compatible with the apache
> license.
> knowledgeable advice would be very welcome.
It is not compatible with ASF policy of allowing users of our software
to create closed-source builds or derivatives. The license starts out
like Apache 1.1 but the final clause is copyleft. However, that clause
only applies to redistribution of the covered code, so it is possible
for us to build an independence layer and let users obtain their own
bdb jar if they so desire.
....Roy
Re: bdb-persistence & db-persistence in contrib
Posted by Alexandru Popescu <th...@gmail.com>.
#: Stefan Guggisberg changed the world a bit at a time by saying on 10/24/2005 5:07 PM :#
> thanks for the feedback.
>
> i moved the code in contrib/db-persistence to core, made
> DerbyPersistenceManager the "default' pm and removed
> CQFileSystem references (r328071).
>
> however, i did not yet move contrib/bdb-persistence to core.
> i realized that this would require adding a berkleydb dependency
> to jackrabbit-core. i didn't know if this would be ok. the most recent
> version of "BerkeleyDB Java Edition" available on http://www.ibiblio.org/maven
> is 1.7.1. the corresponding license can be found here:
> http://www.ibiblio.org/maven/berkeleydb/licenses/je-1.7.1.license
>
> IANAL but the license is certainly not compatible with the apache license.
> knowledgeable advice would be very welcome.
>
> cheers
> stefan
>
2 points here:
1/ berkley db is now at 2.0.83 version. I am working with this version for a couple of days and I
haven't noticed any problems so far.
2/ I have read the license for 1.7.1. IANAL too :-), but i was unable to understand what
contradiction would be with apache license. But probably you have better rules defined. IMO it looks
like in MIT license direction.
./alex
--
.w( the_mindstorm )p.
Re: bdb-persistence & db-persistence in contrib
Posted by Stefan Guggisberg <st...@gmail.com>.
thanks for the feedback.
i moved the code in contrib/db-persistence to core, made
DerbyPersistenceManager the "default' pm and removed
CQFileSystem references (r328071).
however, i did not yet move contrib/bdb-persistence to core.
i realized that this would require adding a berkleydb dependency
to jackrabbit-core. i didn't know if this would be ok. the most recent
version of "BerkeleyDB Java Edition" available on http://www.ibiblio.org/maven
is 1.7.1. the corresponding license can be found here:
http://www.ibiblio.org/maven/berkeleydb/licenses/je-1.7.1.license
IANAL but the license is certainly not compatible with the apache license.
knowledgeable advice would be very welcome.
cheers
stefan
Re: bdb-persistence & db-persistence in contrib
Posted by Edgar Poce <ed...@gmail.com>.
Hi stefan
On 10/14/05, Stefan Guggisberg <st...@gmail.com> wrote:
> folks!
>
> 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
>
> reasons for doing so would IMO be:
> - there are currently only filesystem-based PMs available in core
> - there is currently no PM in core supporting transactions
> - we could leverage Derby, a sister apache project, as default
> transactional persistence layer for jackrabbit
> - we can get rid of CQFileSystem which is non-transactional,
> non-opensource and not free for commercial use
>
> what do you think?
>
I think it's a good idea. +1 from me.
br,
edgar
> cheers
> stefan
>
Re: bdb-persistence & db-persistence in contrib
Posted by Alexandru Popescu <th...@gmail.com>.
#: Jukka Zitting changed the world a bit at a time by saying on 10/15/2005 3:00 PM :#
> Hi,
>
> Stefan Guggisberg wrote:
>> 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
>
> +1
>
> BR,
>
> Jukka Zitting
>
Even if I am not so advanced in these topics I can say that blob manipulation in known databases
doesn't show so far good performances. From this perspective I guess a better solution is using
Berkley DB which is able to store blobs on filesystem so removing this performance penalty. Don't
know if the same is true about Derby.
./alex
--
.w( the_mindstorm )p.
Re: bdb-persistence & db-persistence in contrib
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Stefan Guggisberg wrote:
> 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
+1
BR,
Jukka Zitting
Re: bdb-persistence & db-persistence in contrib
Posted by Alexandru Popescu <th...@gmail.com>.
#: Stefan Guggisberg changed the world a bit at a time by saying on 10/14/2005 5:14 PM :#
> hi walter
>
> On 10/14/05, Walter Raboch <wr...@ingen.at> wrote:
>> Hi all,
>>
>> I am currently developing a database PM based on Hibernate 3 and a
>> "fully" normalized DB schema (also for binaries). I will post my
>> experiences as soon as I have a fully working system - which I estimate
>> within the next week.
>
> cool, looking forward hearing back from you.
>
> just being curious: why did you choose an object-relational db instead
> of a plain relational db?
who mentioned object-relational db? Hibernate works against RDBMS so it is pure relational.
The benefits of working with a ORM solution were discussed many times, and the pros and cons were
presented. Sure, someone may choose to do it with pure JDBC, iBatis mappings or whatever solution he
may like ;-).
couldn't resist it,
./alex
--
.w( the_mindstorm )p.
representing jackrabbit's primitive ItemState objects
> in a normalized sql schema should be straightforward. what's the benefit of
> the object-relational mapping?
>
> cheers
> stefan
>
>>
>> cheers
>> Walter
>>
>>
>
Re: bdb-persistence & db-persistence in contrib
Posted by Stefan Guggisberg <st...@gmail.com>.
hi walter
On 10/14/05, Walter Raboch <wr...@ingen.at> wrote:
> Hi all,
>
> I am currently developing a database PM based on Hibernate 3 and a
> "fully" normalized DB schema (also for binaries). I will post my
> experiences as soon as I have a fully working system - which I estimate
> within the next week.
cool, looking forward hearing back from you.
just being curious: why did you choose an object-relational db instead
of a plain relational db? representing jackrabbit's primitive ItemState objects
in a normalized sql schema should be straightforward. what's the benefit of
the object-relational mapping?
cheers
stefan
>
> cheers
> Walter
>
>
Re: bdb-persistence & db-persistence in contrib
Posted by Walter Raboch <wr...@ingen.at>.
Hi all,
I am currently developing a database PM based on Hibernate 3 and a
"fully" normalized DB schema (also for binaries). I will post my
experiences as soon as I have a fully working system - which I estimate
within the next week.
cheers
Walter
Re: bdb-persistence & db-persistence in contrib
Posted by Stefan Guggisberg <st...@gmail.com>.
hi tomislav,
On 10/14/05, Tomislav Randjic <to...@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
>
>
RE: bdb-persistence & db-persistence in contrib
Posted by Tomislav Randjic <to...@smartsol.co.yu>.
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..
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