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 09:46:06 GMT

On 10.08.2011, at 11:37, Jukka Zitting wrote:

> Hi,
> 
> On Wed, Aug 10, 2011 at 11:11 AM, Lukas Kahwe Smith <mls@pooteeweet.org> 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
mls@pooteeweet.org




Mime
View raw message