jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Herman" <MHer...@NBME.org>
Subject RE: SQL2 (via davex)
Date Wed, 10 Aug 2011 15:24:36 GMT
I think your problem is that you're trying to use your structure as an
implicit property of your content.  One of the ideas behind JCR is that your
content is most important and your structure is less important.  If it is
important to your content then it should be part of your content, not implied
by its structure.  Personally I see two major reasons for this:
 
 1 - since it's implied, you can't be 100% sure what it means.  For example
organizing by date like folders, is it the date the content was created, or
the date it was published, or some other date?
 2 - if you want to change your structure, you have to go in and change every
single query that relies on that structure.  If you do your JCR setup right,
most if not all your queries should stay the same.

For example, if you create your my:issue nodetype with a publishedDate
property, to find all your available dates would just be something like:
(warning: quick pseudo example)

SELECT issue.publishedDate FROM [my:issue] AS issue ORDER BY
issue.publishedDate DESC
(not sure if some form of "SELECT DISTINCT" could be accomplished)

You can change your structure multiple times, but that query will still work.
Never done it before, but I'm guessing it'll also make it easier to do
between date queries.  In the real world it's not always that simple so they
give you a few functions to help.  If you have my:issue nodes all over your
repo but all you really want is everything in your "published" folder, you
could use ISDESCENDANTNODE('/published').  Even better yet you would have a
my:published node and use ISDESCENDANTNODE([my:published]).  Again that way
your structure can change drastically but your queries mean the same thing.

You don't necessarily have to create a custom node type, you could just use
unstructured and use a specific property to filter them by, but that will add
an extra clause to all your queries.  I think creating a custom node type
will usually pay off in the long run unless your content is so dynamic that
you constantly need to update your nodetype.


-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Wed 8/10/2011 6:14 AM
To: users@jackrabbit.apache.org
Subject: Re: SQL2 (via davex)
 

On 10.08.2011, at 12:04, Jukka Zitting wrote:
...
So to summarize I would still like to see PATH() (so that I can sort on that)
and DEPTH() (so that for this use case I would not need a custom node type)
implemented :)

regards,
Lukas Kahwe Smith
mls@pooteeweet.org






Mime
View raw message