You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Martin Perez <mp...@gmail.com> on 2005/10/28 15:02:17 UTC
search operation returning frozenNodes
Hi again.
I insert a node on the repository. Only a unique node with type mix:content.
If i do a search like //element(*,mix:content)[jcr:contains(.'phrase')] then
two results are returned one of type mix:content and other one of type
nt:frozenNode. Is there any way to filter out that frozenNode (versions?)
results?
Thanks
Martin
Re: search operation returning frozenNodes
Posted by Martin Perez <mp...@gmail.com>.
Forgive me again :(
Again, false alarm. It was a problem with Eclipse. When debugging, instead
of going to the line where the exception is catched, he enters an inifinite
loop. But it's an Eclipse problem. If you do the same without debugging then
the InvalidQueryException is thrown perfectly.
Sorry for your time :(
Thanks!
On 10/31/05, Marcel Reutegger <ma...@gmx.net> wrote:
>
> Martin Perez wrote:
> > Well, maybe I used wrongly the word "hangs", but that's a problem with
> my
> > english :-). Most correctly: the query does not returns, maybe it enters
> an
> > infinite loop.
> >
> > I have reproduced the same query just some minutes ago. What do you need
> to
> > reproduce it?
>
> sequence of operation to create sample content, including versioning
> operations and finally the exact query you execute.
>
> or, you could just paste the thread-dump of the jvm when you think the
> query might be in an infinite loop. usually this is also quite
> informative...
>
> regards
> marcel
>
Re: search operation returning frozenNodes
Posted by Marcel Reutegger <ma...@gmx.net>.
Martin Perez wrote:
> Well, maybe I used wrongly the word "hangs", but that's a problem with my
> english :-). Most correctly: the query does not returns, maybe it enters an
> infinite loop.
>
> I have reproduced the same query just some minutes ago. What do you need to
> reproduce it?
sequence of operation to create sample content, including versioning
operations and finally the exact query you execute.
or, you could just paste the thread-dump of the jvm when you think the
query might be in an infinite loop. usually this is also quite
informative...
regards
marcel
Re: search operation returning frozenNodes
Posted by Martin Perez <mp...@gmail.com>.
Well, maybe I used wrongly the word "hangs", but that's a problem with my
english :-). Most correctly: the query does not returns, maybe it enters an
infinite loop.
I have reproduced the same query just some minutes ago. What do you need to
reproduce it?
Regards.
On 10/31/05, Marcel Reutegger <ma...@gmx.net> wrote:
>
> Martin Perez wrote:
> >>My Mistake Marcel. I was using == on the query instead of =. If you use
> =
> >>then it runs ok.
> >
> >
> > Thanks, and sorry for the false alarm :)
>
> no worries. still, I'm a bit concerned because you said jackrabbit hung
> when you executed your query. this should definitively not happen on a
> malformed query.
>
> my quick test returned the expected InvalidQueryException. but if you
> can reproduce it I'd like to know what causes it.
>
> regards
> marcel
>
Re: search operation returning frozenNodes
Posted by Marcel Reutegger <ma...@gmx.net>.
Martin Perez wrote:
>>My Mistake Marcel. I was using == on the query instead of =. If you use =
>>then it runs ok.
>
>
> Thanks, and sorry for the false alarm :)
no worries. still, I'm a bit concerned because you said jackrabbit hung
when you executed your query. this should definitively not happen on a
malformed query.
my quick test returned the expected InvalidQueryException. but if you
can reproduce it I'd like to know what causes it.
regards
marcel
Re: search operation returning frozenNodes
Posted by Martin Perez <mp...@gmail.com>.
>
> My Mistake Marcel. I was using == on the query instead of =. If you use =
> then it runs ok.
Thanks, and sorry for the false alarm :)
Martin
> 4 - //element(*,mix:content)[jcr:contains(.'phrase') and @jcr:primaryType
> > =='nt:frozenNode'] : And also very interesting; this query does not
> return
> > anything. It hangs !!!
>
> could you create a jira issue and attach a thread-dump when jackrabbit
> hangs. that will help a lot to fix this issue.
>
> and just to avoid confusion. I assume the two typos in the query are
> just copy-paste mistakes, right?
>
> what you really execute as query is the following, I assume:
>
> //element(*,mix:content)[jcr:contains(.,'phrase') and @jcr:primaryType
> = 'nt:frozenNode']
>
> regards
> marcel
>
Re: search operation returning frozenNodes
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Martin,
Martin Perez wrote:
> 1 - I don't know if it's very normal that a query return "version" nodes. If
> the spec. does not says something about this, then maybe we're looking at a
> possible improvement area.
versions of a node are part of the workspace where the regular nodes
live in. that means you can use any facility that works for othere nodes
as well, if applicable. e.g. versions of a node are observable and you
may also query them.
> Ok, and now. My frozen node has {http://www.jcp.org/jcr/nt/1.0}frozenNode as
> primaryTypeName attribute value (I'm putting this because maybe it could
> affect the xpath queries). So:
>
> 2 - //element(*,mix:content)[jcr:contains(.'phrase')] : This query returns
> two results. One of type mix:content and another one of type nt:frozenNode
because version are located in a well defined tree you may also exlcude
them with a query that does not include he /jcr:system subtree:
/jcr:root/mycontent/element(*,mix:content)[jcr:contains(.,'phrase')]
> 3 - //element(*,mix:content)[jcr:contains(.'phrase') and @jcr:primaryType
> !='nt:frozenNode'] : This query returns 0 results.
this is a bug and is tracked with jira issue JCR-266. I've fixed it
already. the svn revision is: 329776
> 4 - //element(*,mix:content)[jcr:contains(.'phrase') and @jcr:primaryType
> =='nt:frozenNode'] : And also very interesting; this query does not return
> anything. It hangs !!!
could you create a jira issue and attach a thread-dump when jackrabbit
hangs. that will help a lot to fix this issue.
and just to avoid confusion. I assume the two typos in the query are
just copy-paste mistakes, right?
what you really execute as query is the following, I assume:
//element(*,mix:content)[jcr:contains(.,'phrase') and @jcr:primaryType
= 'nt:frozenNode']
regards
marcel
Re: search operation returning frozenNodes
Posted by Martin Perez <mp...@gmail.com>.
Well, some comments about this:
1 - I don't know if it's very normal that a query return "version" nodes. If
the spec. does not says something about this, then maybe we're looking at a
possible improvement area.
Ok, and now. My frozen node has {http://www.jcp.org/jcr/nt/1.0}frozenNode as
primaryTypeName attribute value (I'm putting this because maybe it could
affect the xpath queries). So:
2 - //element(*,mix:content)[jcr:contains(.'phrase')] : This query returns
two results. One of type mix:content and another one of type nt:frozenNode
3 - //element(*,mix:content)[jcr:contains(.'phrase') and @jcr:primaryType
!='nt:frozenNode'] : This query returns 0 results.
4 - //element(*,mix:content)[jcr:contains(.'phrase') and @jcr:primaryType
=='nt:frozenNode'] : And also very interesting; this query does not return
anything. It hangs !!!
Comments?
Thanks!
Re: search operation returning frozenNodes
Posted by Marcel Reutegger <ma...@gmx.net>.
did you try?
//element(*,mix:content)[jcr:contains(.'phrase') and @jcr:primaryType !=
'nt:frozenNode']
regards
marcel
Martin Perez wrote:
> Hi again.
>
> I insert a node on the repository. Only a unique node with type mix:content.
>
>
> If i do a search like //element(*,mix:content)[jcr:contains(.'phrase')] then
> two results are returned one of type mix:content and other one of type
> nt:frozenNode. Is there any way to filter out that frozenNode (versions?)
> results?
>
> Thanks
>
> Martin
>