jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: Jackrabbit, the database
Date Sat, 18 Aug 2007 06:55:30 GMT

> moving away not only from RDBMS systems as core storage

I agree. RDBMS are not the best way to store hierarchical data.

> but also away from their query languages such as SQL.

SQL is a very old and strange language. It does not fit very well with
languages such as Java. Replacing it would be great.

For some technologies, it seems that disruptive changes failed, but
'step-by-step replacement' is successful:

- Replacing RDBMS with disruptive changes have failed in my view:
object databases, XML databases. But O/R mapping is successful.

- Chip industry: replacing x86 technology with disruptive changes has
failed, the 'compatibility approach' was more successful.

- Cars: the all-electric car has failed. The hydrogen car has failed.
But hybrid cars are successful.

- OS/2 failed, but Windows was successful (because of better MS-DOS

(There is probably a book about that, similar to 'The Innovator's
Dilemma', but I don't know it).

> Jackrabbit be refactored so that each session would map to a separate database connection.

I don't think it can be done in the short term. But we should
investigate it for Next Generation Persistence
(http://jackrabbit.apache.org/dev/ngp.html). We need specific use
cases where using multiple connections clearly helps: A test-first
approach (or test-driven-development, or TDD).

> don't like having the database being a driving factor in Jackrabbit design. The way I
see it we should be moving further away from relational databases, towards a native hierarchical
storage model.

I agree, but some customers are more comfortable when using RDBMS as
the storage. It maybe a perceived advantage only.

In my view the 'compatibility approach' is great: provide RDBMS
persistence managers, but work on better persistence managers (that
are optimized for JCR storage).

The same for Global Data Store: FileDataStore is the most logical
solution. Large objects are not a good fit for databases. Anyway some
still want to store them in a database. So we support a
DatabaseDataStore as well.


View raw message