Hi Michael,
Michael Aemisegger wrote:
Dear list
I'm wondering whether you would advise to store data objects which have
a many-to-many relationship in a repository instead of a RDBMS.
this is certainly possible with JSR-170 using reference properties to
model the many-to-many relationship.
The challenge I see is to do queries against the repository for such a
data model.
For some applications you won't even need a query at all.
e.g. if you are looking for all students of a certain prof you can
simply use the API without executing a query:
depending on the direction of your references you either use:
Node prof = ...
PropertyIterator profRefs = prof.getReferences();
which will give you the properties of student nodes that reference the
prof you are interested in.
or:
Node profs = ...
Value[] studentUUIDs = prof.getProperty("profs").getValues();
which will return the UUIDs of the student nodes.
I'd like to query something like
'SELECT prof.name, student.name FROM prof, student WHERE
prof.id=student.profId'
to simply resolve relations like the above you should rather use the jcr
api. if you want to apply additional constraints to the query you should
probably use the jcr:deref() function in XPath. See below.
Are Joins supported in level 1 repositories?
Level 1 repositories are only required to support XPath, SQL is an
optional feature. Which means even a Level 2 repository is not required
to support it. Though some JCR implementations based on a database will
probably support some sort of joins, but in a non-standardized way.
Are they supported in Jackrabbit?
joins in SQL are not supported in jackrabbit. The preferred language to
query a workspace is XPath, because it can easier cope with the
hierarchical structure.
Is there a natural way to formulate this kind of query in XPATH?
the jcr:deref() function is probably what you are looking for. It allows
you to resolve reference properties in a path step.
e.g.:
profs/[EMAIL PROTECTED] = 'michi']/jcr:deref(@students, '*')[EMAIL PROTECTED] =
'graduate']
returns the graduate students of prof michi.
assuming profs reference students with the @students property.
See also chapter 6.6.5.4 of the jsr-170 spec. Note that the jcr:deref()
function is optional.
regards
marcel
