Jackrabbit, the database

[Jukka Zitting <ju...@gmail.com>]

Hi,

Late night ramblings...

There's recently been a lot of talk about managing the database
connections (and transactions) of the Jackrabbit persistence managers.
It was even suggested that Jackrabbit be refactored so that each
session would map to a separate database connection.

Improvements in the way an underlying database is used are of course
welcome, but in the big picture I 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 don't want Jackrabbit using a database, I want Jackrabbit *being*
the database!

BR,

Jukka Zitting

Re: Jackrabbit, the database

[Christophe Lombart <ch...@gmail.com>]

On 8/18/07, Jukka Zitting <ju...@gmail.com> wrote:
>
>
>
> I don't want Jackrabbit using a database, I want Jackrabbit *being*
> the database!



+1 but we need more administration tools. I mean in the open source area :-)

BR,
>
> Jukka Zitting
>

Re: Jackrabbit, the database

[Thomas Mueller <th...@gmail.com>]

Hi,

> 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
compatibility?)

(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.

Thomas

Re: Jackrabbit, the database

[Padraic Hannon <pi...@wasabicowboy.com>]

On a similar subject, has any one looked at Freebase? It is built upon 
Metaweb which is described in their manual as: "A Metaweb database is a 
sea of knowledge organized as a graph: a set of nodes and a set of links 
or relationships between those nodes."

After playing with it for a while it is very similar in concept to 
jackrabbit/jcr however it is primarily using json for queries and object 
representation. This an mix-ins is what is sparking my dynamic typing 
thoughts. My point in bringing this up is that there seems to be a 
movement illustrated by both jcr and this metaweb idea which is a step 
back and at the same time a forward movement towards tree based data 
structures with reference-able links. Perhaps this also means moving 
away not only from RDBMS systems as core storage but also away from 
their query languages such as SQL. The metaweb json system is extremely 
interesting and seems easy and powerful, worth taking a look at.



-paddy

Re: Jackrabbit, the database

[Padraic Hannon <pi...@wasabicowboy.com>]

If Jackrabbit is to be the database then things such as transaction 
isolation levels, etc. need to be addressed. If Jackrabbit uses a 
database (ie derby) some of those can be off loaded to the db. However, 
in that case Jackrabbit becomes yet another, albeit extremely 
interesting, wrapper around an RDBMS. I think Jackrabbit is much more 
than an RDBMS wrapper and that developing the API is just a part of the 
overall system. IMO, moving away from derby and into a native storage 
system sounds like the right direction.


Jukka Zitting wrote:
> Hi,
>
> Late night ramblings...
>
> There's recently been a lot of talk about managing the database
> connections (and transactions) of the Jackrabbit persistence managers.
> It was even suggested that Jackrabbit be refactored so that each
> session would map to a separate database connection.
>
> Improvements in the way an underlying database is used are of course
> welcome, but in the big picture I 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 don't want Jackrabbit using a database, I want Jackrabbit *being*
> the database!
>
> BR,
>
> Jukka Zitting
>   

Re: Jackrabbit, the database

[Stefan Guggisberg <st...@gmail.com>]

On 8/18/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> Late night ramblings...
>
> There's recently been a lot of talk about managing the database
> connections (and transactions) of the Jackrabbit persistence managers.
> It was even suggested that Jackrabbit be refactored so that each
> session would map to a separate database connection.
>
> Improvements in the way an underlying database is used are of course
> welcome, but in the big picture I 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 don't want Jackrabbit using a database, I want Jackrabbit *being*
> the database!

i couldn't agree more...

cheers
stefan

>
> BR,
>
> Jukka Zitting
>