XPATH query with jcr:contains - weird behavior
87 views
Skip to first unread message
Jennifer Amon
Apr 23, 2018, 11:36:33 AM4/23/18
to Hippo Community
This works as an XPATH query in the repository servlet at /cms/repository, AND as an XPath query for an Updater/Editor script:
/jcr:root/content/documents/us-en/products//element(*,mix:versionable)[jcr:contains(@xyz:readOnlyProductUrl, "products/Arbor")]
However, if I remove one letter from the end of the jcr:contains match string, it does not throw an error, but returns 0 nodes:
/jcr:root/content/documents/us-en/products//element(*,mix:versionable)[jcr:contains(@xyz:readOnlyProductUrl, "products/Arbo")]
The actual values of xyz:readOnlyProductUrl look like these:
/products/Arbor/subpath/sku
/products/Arbor-with.../subpath/sku
Why would the first query work to pull both of the above nodes, but not the 2nd query? What am I missing?
The ultimate goal is to have the query results include only those products under .../products/a*, where a* is all of the next level nodes that start with a.
Once the first one worked, I expected to be able to shorten the jcr:contains match string to just "products/A" - no such luck.
Any hints/suggestions?
Thanks in Advance!!
Woonsan Ko
Apr 23, 2018, 11:53:26 AM4/23/18
to hippo-c...@googlegroups.com
On Mon, Apr 23, 2018 at 11:36 AM, Jennifer Amon <vang...@gmail.com> wrote:
This works as an XPATH query in the repository servlet at /cms/repository, AND as an XPath query for an Updater/Editor script:/jcr:root/content/documents/us-en/products//element(*,mix:versionable)[jcr:contains(@xyz:readOnlyProductUrl, "products/Arbor")]However, if I remove one letter from the end of the jcr:contains match string, it does not throw an error, but returns 0 nodes:/jcr:root/content/documents/us-en/products//element(*,mix:versionable)[jcr:contains(@xyz:readOnlyProductUrl, "products/Arbo")]The actual values of xyz:readOnlyProductUrl look like these:/products/Arbor/subpath/sku/products/Arbor-with.../subpath/skuWhy would the first query work to pull both of the above nodes, but not the 2nd query? What am I missing?
jcr:contains() makes it as full text search query and "Terms separated by whitespace are implicitly “ANDed”. [1] I think that's why.
The ultimate goal is to have the query results include only those products under .../products/a*, where a* is all of the next level nodes that start with a.Once the first one worked, I expected to be able to shorten the jcr:contains match string to just "products/A" - no such luck.Any hints/suggestions?
In your case, this seems more proper:
/jcr:root/content/documents/us-en/products//element(*,mix:versionable)[jcr:like(@xyz:readOnlyProductUrl, "products/A%")]
Regards,
Woonsan
--Thanks in Advance!!
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
To post to this group, send email to hippo-community@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.
Jennifer Amon
Apr 23, 2018, 12:07:50 PM4/23/18
to Hippo Community
Hmmm. There is no difference in the white space from one to the other, is there. I changed Arbor to Arbo
jcr:like does work. Thank you!
However, that still does not explain the weird behavior.
On Monday, April 23, 2018 at 11:53:26 AM UTC-4, woonsan.ko wrote:
On Mon, Apr 23, 2018 at 11:36 AM, Jennifer Amon <vang...@gmail.com> wrote:This works as an XPATH query in the repository servlet at /cms/repository, AND as an XPath query for an Updater/Editor script:/jcr:root/content/documents/us-en/products//element(*,mix:versionable)[jcr:contains(@xyz:readOnlyProductUrl, "products/Arbor")]However, if I remove one letter from the end of the jcr:contains match string, it does not throw an error, but returns 0 nodes:/jcr:root/content/documents/us-en/products//element(*,mix:versionable)[jcr:contains(@xyz:readOnlyProductUrl, "products/Arbo")]The actual values of xyz:readOnlyProductUrl look like these:/products/Arbor/subpath/sku/products/Arbor-with.../subpath/skuWhy would the first query work to pull both of the above nodes, but not the 2nd query? What am I missing?jcr:contains() makes it as full text search query and "Terms separated by whitespace are implicitly “ANDed”. [1] I think that's why.The ultimate goal is to have the query results include only those products under .../products/a*, where a* is all of the next level nodes that start with a.Once the first one worked, I expected to be able to shorten the jcr:contains match string to just "products/A" - no such luck.Any hints/suggestions?In your case, this seems more proper:/jcr:root/content/documents/us-en/products//element(*,mix:versionable)[jcr:like(@xyz:readOnlyProductUrl, "products/A%")]Regards,Woonsan
Thanks in Advance!!
--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
To post to this group, send email to hippo-c...@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.
Ard Schrijvers
Apr 23, 2018, 3:35:14 PM4/23/18
to hippo-c...@googlegroups.com
On Mon, Apr 23, 2018 at 6:07 PM, Jennifer Amon <vang...@gmail.com> wrote:
> Hmmm. There is no difference in the white space from one to the other, is
> there. I changed Arbor to Arbo
>
> jcr:like does work. Thank you!
In general I strongly discourage the usage of jcr:like, but if you
> Hmmm. There is no difference in the white space from one to the other, is
> there. I changed Arbor to Arbo
>
> jcr:like does work. Thank you!
make sure there are enough chars before the '%' it cannot harm that
much. Otherwise, jcr:like easily blows up the memory. An artifact of
Lucene wildcard queries
>
> However, that still does not explain the weird behavior.
tokenized on the '/' and thus it results in 'products AND Arbo' and
this combination does not occur in the Lucene index (inverted index).
Regards Ard
Hippo USA, Inc. 71 Summer Street, 2nd Floor Boston, MA 02110, United
states of America.
www.onehippo.com
Reply all
Reply to author
Forward
0 new messages