Is the xpath 'union' operator supported in jackrabbit?
Is the xpath 'union' operator supported in jackrabbit? For example, /jcr:root/a/b/[EMAIL PROTECTED]"bar"] union /jcr:root/a/c/[EMAIL PROTECTED]"bar"].or must this be done using 2 separate queries and merged by the user? It appears I can use SQL with the jcr:path and the or conjunction to get this same result but in a single query. David
CND x XML compatibility for custom node definition.
In the following xml definition:
nt:hierarchyNode
xxx:user
xxx:security
I defined that the prop:creator is a property that may only refers to a node of
type xxx:user (restriction), and a node with the name "Permission" of type
xxx:security will autocreate with the creation of the node of type xxx:base.
Registering this file, the repository works as expected.
I have defined the same structure in a file with the cnd format, so the file is
like this:
http://www.e/1.0'>
http://www.p/1.0'>
[xxx:base] > nt:hierarchyNode
- prop:creatir (reference)
version
< 'xxx:user'
+ Permission (xxx:security)
= xxx:security
autocreated version
[xxx:user] > nt:hierarchyNode
[xxx:security] > nt:hierarchyNode
Why when trying to register the nodetype, it gets me two errors ?:
1 - About to the restriction for the value in the prop:creator only may refers
to xxx:user:
javax.jcr.RepositoryException:
[{http://www.e/1.0}base#{http://www.e/1.0}creator] invalid REFERENCE value
constraint '{http://www.e/1.0}user' (unknown node type)
2 - About the name the node will autocreate, if I keep like "Permission" it
says me that the name is invalid for jcr, it must be "xxx:Permission".
How to do the register in cnd format recognize all I declared like I did in xml
format? I thought the cnd format has all the parameters that xml format has.
Helio
RE: Simple queries failing
Hi David,
If you check out the JCR spec in section 6.6.4.3 (Context Node) it says
that every Xpath query must start with the pseudo-root context node
named "jcr:root". To quote:
<<
The context node of an XPath query is the XML node relative to which the
query expression is evaluated.
A relative XPath statement (one that does not have a leading /) will be
interpreted relative to the root node of the workspace, which, in the
XML document view is the top-most XML element, . This means
that one should not include jcr:root as the first segment in a relative
XPath statement, since that element is already the default context node.
An absolute XPath (one with a leading /), in contrast, will be
interpreted relative to a position one level above . This
means that an absolute XPath must either begin with // or with /jcr:root
in order to match anything at all.
>>
Hope that helps,
-- Mike
> -Original Message-
> From: David Kennedy [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 27, 2006 3:11 PM
> To: dev@jackrabbit.apache.org
> Subject: Simple queries failing
>
> I am trying to execute very simple queries using the default
> repository setup and the queries are failing:
>
> Here is how I'm getting the QueryManager and executing the query
>
> String statement = "/Perf";
> QueryManager queryManager =
> (QueryManager)workspace.getQueryManager();
> Query query = queryManager.createQuery(statement, Query.XPATH);
> QueryResult qResult = query.execute();
> NodeIterator iter = qResult.getNodes();
> System.out.println("Query = " + statement + " #hits = " +
> iter.getSize());
>
> The iterator size is always 0. My hierarchy starts with
> /Perf and there
> are many nodes below Perf. I have a repository explorer
> that displays the hierarchy and confirms the nodes are there.
> Is there something I'm missing? Where would you begin to
> debug this? I've traced it to the LuceneQueryBuilder, but
> haven't gone much further. How can I determine what's in the indices?
>
> David
>
NOTICE: If received in error, please destroy and notify sender. Sender does
not waive confidentiality or privilege, and use is prohibited.
Simple queries failing
I am trying to execute very simple queries using the default repository
setup and the queries are failing:
Here is how I'm getting the QueryManager and executing the query
String statement = "/Perf";
QueryManager queryManager = (QueryManager)workspace.getQueryManager();
Query query = queryManager.createQuery(statement, Query.XPATH);
QueryResult qResult = query.execute();
NodeIterator iter = qResult.getNodes();
System.out.println("Query = " + statement + " #hits = " +
iter.getSize());
The iterator size is always 0. My hierarchy starts with /Perf and there
are many nodes below Perf. I have a repository explorer that displays
the hierarchy and confirms the nodes are there. Is there something I'm
missing? Where would you begin to debug this? I've traced it to the
LuceneQueryBuilder, but haven't gone much further. How can I determine
what's in the indices?
David
Re: namespace resolution error
On 4/27/06, Stefan Guggisberg <[EMAIL PROTECTED]> wrote: > hmm, pretty weird indeed... is it reproducable? i suggest you place > a break point where the UnknownPrefixException is thrown and do > a little debugging. yeah, and it turns out to have been pilot error - i had created the repository using localfs filesystems and persistence managers, but i was attempting to run it with a derby-based configuration, so the namespace registry had none of my custom namespaces registered. der!!
[jira] Resolved: (JCR-411) Binding repository to a nameserver with RegistryHelper causes failure on lookup.
[ http://issues.apache.org/jira/browse/JCR-411?page=all ] Stefan Guggisberg resolved JCR-411: --- Fix Version: 1.0.1 Resolution: Fixed fixed in svn rev. 397583 thanks for reporting this issue! > Binding repository to a nameserver with RegistryHelper causes failure on > lookup. > > > Key: JCR-411 > URL: http://issues.apache.org/jira/browse/JCR-411 > Project: Jackrabbit > Type: Bug > Components: core > Versions: 1.0 > Environment: Windows XP SP2, JBoss 4.0.3SP1 > Reporter: Mark Moales > Assignee: Stefan Guggisberg > Fix For: 1.0.1 > > Binding a repository to a nameserver using RegistryHelper causes the next > subsequent lookup to fail. This is what I observerd: > 1. RegistryHelper.registerRepository creates a new BindableRepository and > initializes it. This, in turn, initializes the "real" repository (i.e. > delagtee). It then binds this reference with the nameserver. > 2. On the next lookup, BindableRepositoryFactory.getObjectInstance is > invoked. Thie method checks it's cache for a repository. Since one does not > exist yet, it creates a new BindableRepository and tries to initialize it. > This fails since the call to RegistryHelper.registerRepository already > initialized the repository. > The error message basically says the repository is already in use by another > process because the .lock file is present. To fix this, I modified > RegistryHelper.registerRepository to NOT initialize the repository and simply > bind the "Reference". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Restricting xpath query to document text
thomasg wrote: Thanks for your reply. To clarify the situation at little. I was expecting to run a query such as: //element(*, axxia:resource)[jcr:contains(@jcr:data, 'classes')] to only search the contents of a document. This does not currently return an expected hit. that's because the node indexer currently populates the node scope index (the one you can query with '.') with the text found in the jcr:data property. Will resolving the issue JCR-415 refered to make such a search possible? yes, at least it will make it possible to replace the default implementation with an indexer that also provides an index for the jcr:data property. regards marcel
Re: Restricting xpath query to document text
Thanks for your reply. To clarify the situation at little. I was expecting to run a query such as: //element(*, axxia:resource)[jcr:contains(@jcr:data, 'classes')] to only search the contents of a document. This does not currently return an expected hit. Will resolving the issue JCR-415 refered to make such a search possible? Meanwhile I've realised that my idea of running query similar to: //element(*, axxia:resource)[jcr:contains(., 'classes') and jcr:contains(@axxia:subject, '-classes) and ... etc, all my properties I want to exclude...] doesn't work logically as won't return a hit if the word is in the document text and a property. I guess my only option is to use a different node structure with the content and properties seperated and run 2 queries rather than 1. Cheers, Thomas -- View this message in context: http://www.nabble.com/Restricting-xpath-query-to-document-text-t1512215.html#a4118705 Sent from the Jackrabbit - Dev forum at Nabble.com.
[jira] Assigned: (JCR-411) Binding repository to a nameserver with RegistryHelper causes failure on lookup.
[ http://issues.apache.org/jira/browse/JCR-411?page=all ] Stefan Guggisberg reassigned JCR-411: - Assign To: Stefan Guggisberg > Binding repository to a nameserver with RegistryHelper causes failure on > lookup. > > > Key: JCR-411 > URL: http://issues.apache.org/jira/browse/JCR-411 > Project: Jackrabbit > Type: Bug > Components: core > Versions: 1.0 > Environment: Windows XP SP2, JBoss 4.0.3SP1 > Reporter: Mark Moales > Assignee: Stefan Guggisberg > > Binding a repository to a nameserver using RegistryHelper causes the next > subsequent lookup to fail. This is what I observerd: > 1. RegistryHelper.registerRepository creates a new BindableRepository and > initializes it. This, in turn, initializes the "real" repository (i.e. > delagtee). It then binds this reference with the nameserver. > 2. On the next lookup, BindableRepositoryFactory.getObjectInstance is > invoked. Thie method checks it's cache for a repository. Since one does not > exist yet, it creates a new BindableRepository and tries to initialize it. > This fails since the call to RegistryHelper.registerRepository already > initialized the repository. > The error message basically says the repository is already in use by another > process because the .lock file is present. To fix this, I modified > RegistryHelper.registerRepository to NOT initialize the repository and simply > bind the "Reference". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Restricting xpath query to document text
thomasg wrote: How can I modify the query to return hits when the word is in the document body and not if it is just in one of the properties? with the current implementation the only way to achieve this is to prohibit the term in another clause for the excluded properties. currently the text representation of a jcr:data property is indexed as part of the node scope fulltext index. but in some cases (such as yours) it is also desirable to have the fulltext index also on the jcr:data property. this however adds some overhead to the node indexing. I think in the end this is something that should be configurable because it is not always needed. I've created an jira issue that describes this enhancement: http://issues.apache.org/jira/browse/JCR-415 Oh, plus another question while I'm at it. Is there any limit (absolute or performance) to the number of clauses one can add to the [] (square bracket) part of the query? Mine potentially could get very large. lucene has a max clauses limit of 1024. though, this can be set to a higher value. jackrabbit does not yet allow to configure this value. wrt performance, the more clauses you have the longer the query will take to execute. in the end this completely depends on lucene. you might be able to find performance information on the lucene website. regards marcel
[jira] Created: (JCR-415) Enhance indexing of binary content
Enhance indexing of binary content -- Key: JCR-415 URL: http://issues.apache.org/jira/browse/JCR-415 Project: Jackrabbit Type: Improvement Components: indexing Versions: 1.0, 0.9 Reporter: Marcel Reutegger Priority: Minor Indexing of binary content should be enhanced in order to allow either configuration what fields are indexed or provide better support for custom NodeIndexer implementations. The current design has a couple of flaws that should be addressed at the same time: - Reader instances are requested from the text filters even though the reader might never be used - only jcr:data properties of nt:resource nodes are fulltext indexed - It is up to the text filter implementation to decide the lucene field name for the text representation, responsibility should be moved to the NodeIndexer. A text filter should only provide a Reader instance. With those changes a custom NodeIndexer can then decide if a binary property has one or more representations in the index. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: namespace resolution error
On 4/26/06, Brian Moseley <[EMAIL PROTECTED]> wrote: i'm having an odd problem looking up a property. the exception is: javax.jcr.RepositoryException: failed to resolve path cosmo:username relative to /r/ro/root: cosmo: cosmo at org.apache.jackrabbit.core.NodeImpl.resolveRelativePropertyPath(NodeImpl.java:190) at org.apache.jackrabbit.core.NodeImpl.getProperty(NodeImpl.java:2283) and the root cause is: org.apache.jackrabbit.name.UnknownPrefixException: cosmo at org.apache.jackrabbit.name.QName.fromJCRName(QName.java:597) at org.apache.jackrabbit.core.CachingNamespaceResolver.getQName(CachingNamespaceResolver.java:89) at org.apache.jackrabbit.core.NamespaceRegistryImpl.getQName(NamespaceRegistryImpl.java:347) at org.apache.jackrabbit.core.LocalNamespaceMappings.getQName(LocalNamespaceMappings.java:169) at org.apache.jackrabbit.core.NodeImpl.resolveRelativePropertyPath(NodeImpl.java:162) at org.apache.jackrabbit.core.NodeImpl.getProperty(NodeImpl.java:2283) checking repository/namespaces/ns_reg.properties, i find that the prefix cosmo is there: #Wed Apr 26 12:22:11 PDT 2006rep=internal xml=http\://www.w3.org/XML/1998/namespace fn=http\://www.w3.org/2004/10/xpath-functions xs=http\://www.w3.org/2001/XMLSchema mix=http\://www.jcp.org/jcr/mix/1.0m ... cosmo=http\://osafoundation.org/cosmo what could be the reason for this prefix lookup failing? hmm, pretty weird indeed... is it reproducable? i suggest you place a break point where the UnknownPrefixException is thrown and do a little debugging.
