On 10.08.2011, at 11:37, Jukka Zitting wrote:
> Hi,
>
> On Wed, Aug 10, 2011 at 11:11 AM, Lukas Kahwe Smith <[email protected]>
> wrote:
>> On 10.08.2011, at 11:02, Jukka Zitting wrote:
>>> The more specific ISSAMENODE, ISCHILDNODE and ISDESCENDANTNODE
>>> constraints in SQL2 were designed to replace the rather vague
>>> "jcr:path LIKE ..." construct in SQL1.
>>
>> But these do not replace all uses cases for wanting to filter on a path.
>
> Together with joins as shown by Mark they should actually be quite a
> bit more powerful than the "jcr:path LIKE ..." construct. What kind of
> a use case are you looking for that isn't covered by these SQL2
> constructs?
>
> I agree that needing multiple joins for something like this is pretty
> verbose, but it should be possible to implement some syntactic sugar
> (perhaps along the lines of "jcr:path LIKE ...") to make such queries
> more compact.
I tried using ISDESCENDANTNODE() but I kept getting 403 errors, like I stated
in the original post.
>>> Regarding your specific use case: If you need a simple way to query
>>> for all the day nodes, you could use a specific node type or a marker
>>> mixin for all those nodes. Then you could simply use a query like
>>> SELECT * FROM [my:day].
>>
>> yeah, but then i would still have no way to do the sort i need,
>
> For that I'd recommend having a DATE property on the day nodes and
> sorting by that:
>
> ORDER BY date
This is essentially what I have now. It was just easier to "automate" setting
the entire path due to how my code is structured.
> If you prefer not to duplicate information from the path, you can use
> a join to get the parent node names:
>
> ORDER BY NAME(years), NAME(months), NAME(days)
Right, but for this I would need the joins to work, plus I would then indeed
have a pretty complex query for something that imho is quite simple: doing a
filter on a path.
>> nor ensure that only day's within a certain subpath are selected:
>
> That should be easy to do with an ISDESCENDANTNODE constraint:
>
> SELECT * FROM [my:day] WHERE ISDESCENDANTNODE('/issues/2011')
Sure, but see above.
> More generally, it could be that we're chasing the wrong solution
> here. Could you describe your use case for needing the list of dates
> as opposed to the list of issues stored within the subtree? Typically
> when using a date-based content tree like this people are only really
> interested in the stuff that's stored at the leaf nodes.
I explained the use case in my original post. What I need to do is to get the
last X days within /issues sorted decending by date
/issues
/issues/2011
/issues/2011/08
/issues/2011/08/02
/issues/2011/08/02/foo
/issues/2011/08/02/bar
/issues/2011/08/09
/issues/2011/08/09/foo
/issues/2011/08/09/bar
So what I need is:
2011/08/02
2011/08/09
regards,
Lukas Kahwe Smith
[email protected]
