Node relationships?

[Robert Campbell <rr...@gmail.com>]

I'm almost done ready the JCR spec, but I don't see any mention of
this particular problem:

A product node can be the child of multiple category nodes (for
example). In a RDBMS you can express relationships between entities
however you wish, in this case I would have a cross-reference table
with product_id and category_id, resulting in products being mapped to
as many categories as you want. The JCR, however, lays out a pretty
strict tree hierarchy preventing multiple parents.

One thought is that I keep the RDBMS for relationship data, and just
have a column in the products table for UUID pointing to the JCR
(which would probably just be flat, each node having a UUID, and not
utilizing the tree structure). This means the DB would have
relationship data, and the JCR would have entity data.

The other thought is scrap the DB and just have a multivalue Category
property on all Product nodes containing the UUID of the Category they
reside in. This feels a bit like a hack, however, and while removing
the need for the DB to store relationships, it still doesn't make use
of the tree structure.

I can't be the first one to encounter this problem, but I can't find
any design patterns to address it.

Rob

Re: Node relationships?

[Julian Reschke <ju...@gmx.de>]

Robert Campbell wrote:
> Thanks Julian; I've started reading JSR-283 and this Shareable Node is
> exactly what I need. I looked at the Jackrabbit roadmap, and support
> for JCR 2.0 is in the "medium term". Does anyone know what this means
> (generally)? Are we talking months or years?

Months, I guess.

Parts of the JSR-283 are already implemented in the trunk; in the 
meantime, you can cast the JSR 170 Node to a JSR 283 Node, which 
contains some of the new functionality -- that's what we used when we 
implemented BIND support in the Jackrabbit WebDAV servlet.

> I'm in a bit of a tough spot because if I go forward with my
> multivalue Category UUID plan, I think that it will be hard to convert
> the CR to use Sharable Nodes in the future once there are thousands of
> nodes in there. On the flip side, using the DB option isn't really any
> better, and it's another entire system.

Can't help you with the release timing question. Maybe Jukka can give an 
estimate when a stable JSR-283 compliant release (2.0?) will be finished.

BR, Julian

Re: Node relationships?

[Robert Campbell <rr...@gmail.com>]

Thanks Julian; I've started reading JSR-283 and this Shareable Node is
exactly what I need. I looked at the Jackrabbit roadmap, and support
for JCR 2.0 is in the "medium term". Does anyone know what this means
(generally)? Are we talking months or years?

I'm in a bit of a tough spot because if I go forward with my
multivalue Category UUID plan, I think that it will be hard to convert
the CR to use Sharable Nodes in the future once there are thousands of
nodes in there. On the flip side, using the DB option isn't really any
better, and it's another entire system.


On Sun, Nov 9, 2008 at 2:45 PM, Julian Reschke <ju...@gmx.de> wrote:
> Robert Campbell wrote:
>>
>> I'm almost done ready the JCR spec, but I don't see any mention of
>> this particular problem:
>>
>> A product node can be the child of multiple category nodes (for
>> example). In a RDBMS you can express relationships between entities
>> however you wish, in this case I would have a cross-reference table
>> with product_id and category_id, resulting in products being mapped to
>> as many categories as you want. The JCR, however, lays out a pretty
>> strict tree hierarchy preventing multiple parents.
>>
>> One thought is that I keep the RDBMS for relationship data, and just
>> have a column in the products table for UUID pointing to the JCR
>> (which would probably just be flat, each node having a UUID, and not
>> utilizing the tree structure). This means the DB would have
>> relationship data, and the JCR would have entity data.
>>
>> The other thought is scrap the DB and just have a multivalue Category
>> property on all Product nodes containing the UUID of the Category they
>> reside in. This feels a bit like a hack, however, and while removing
>> the need for the DB to store relationships, it still doesn't make use
>> of the tree structure.
>>
>> I can't be the first one to encounter this problem, but I can't find
>> any design patterns to address it.
>
> I think a multivalued category property should work just fine; but yes, it
> doesn't take advantage of hierarchical storage.
>
> If you *do* want to use that, the Shareable Nodes feature specified in
> JSR-283 may be the right thing for you; essentially it allows a single node
> to appear below multiple parent nodes (it's almost a one to one match to the
> WebDAV BIND specification).
>
> Best regards, Julian
>
>

Re: Node relationships?

[Julian Reschke <ju...@gmx.de>]

Robert Campbell wrote:
> I'm almost done ready the JCR spec, but I don't see any mention of
> this particular problem:
> 
> A product node can be the child of multiple category nodes (for
> example). In a RDBMS you can express relationships between entities
> however you wish, in this case I would have a cross-reference table
> with product_id and category_id, resulting in products being mapped to
> as many categories as you want. The JCR, however, lays out a pretty
> strict tree hierarchy preventing multiple parents.
> 
> One thought is that I keep the RDBMS for relationship data, and just
> have a column in the products table for UUID pointing to the JCR
> (which would probably just be flat, each node having a UUID, and not
> utilizing the tree structure). This means the DB would have
> relationship data, and the JCR would have entity data.
> 
> The other thought is scrap the DB and just have a multivalue Category
> property on all Product nodes containing the UUID of the Category they
> reside in. This feels a bit like a hack, however, and while removing
> the need for the DB to store relationships, it still doesn't make use
> of the tree structure.
> 
> I can't be the first one to encounter this problem, but I can't find
> any design patterns to address it.

I think a multivalued category property should work just fine; but yes, 
it doesn't take advantage of hierarchical storage.

If you *do* want to use that, the Shareable Nodes feature specified in 
JSR-283 may be the right thing for you; essentially it allows a single 
node to appear below multiple parent nodes (it's almost a one to one 
match to the WebDAV BIND specification).

Best regards, Julian