jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tako Schotanus" <quinte...@gmail.com>
Subject Re: importing jackrabbit into jackrabbit
Date Fri, 27 Apr 2007 09:04:53 GMT
On 4/27/07, David Nuescheler <david.nuescheler@gmail.com> wrote:
> > It's easy to see how, in a large company, there could be thousands of
> > employee holding the same position and health plan, and those
> > specific nodes ("Secretary" and "Plan A")  would have thousand of
> > references pointing to them.
> > So, given the issue  as explained by Marcel that "whenever a
> > reference is added that points to a node N the complete set of
> > references pointing to N is re-written to the persistence manager",
> > it seems that using references to a node that is very "popular" is
> > really going to be creating problems in the long term.
> Agreed. And I think we will not be able to re-educate everybody with
> an RDBMS background before using Jackrabbit so I think Jackrabbit has
> to be able to deal with very large quantities of references in a very
> efficient way.

I think "re-educate" is not the proper word to use here, there are very
valid reasons for wanting referential integrity. Making a system that
handles the health and pension plans for thousands of employees in a large
organization might require exactly that level of data-security. Saying you
can do the same in (newly made, largely untried) code as a (well-known,
stable, proven) RDMS might not convince everyone, especially when the data
is very important.

So yes, I agree that Jackrabbit should try to make this use-case perform
well but not because of uneducated RDMS programmers but because sometimes a
lot of references are necessary and no amount of redesigning your data
structures will help.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message