jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Kahwe Smith <...@pooteeweet.org>
Subject Re: SQL2 (via davex)
Date Wed, 10 Aug 2011 21:47:43 GMT

On 10.08.2011, at 17:24, Mark Herman wrote:

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

yeah i see your point and i thought about this as well. the structure is basically articles
under /issue which are just spread out by date. if an article appears in multiple dates we
will use references.

so the final approach looks like i will use properties instead of custom node types for two
1) i need to sort by the date
2) i would like custom node types as much as possible because it feels like its going to complicate
moving the content between setups

thx for your feedback!

Lukas Kahwe Smith

View raw message