Lucene combined query - Wildcards failure?

[sergio]

Hi all.

My problems with Lucene go on, and I am becoming crazy!

The following query:

+PARENT:"workspace://SpacesStore/a169fc91-9a45-11db-8c36-4fedb9902cf2" AND +@\{http\://www.alfresco.org/model/content/1.0\}name:'20060919_tizio_test1.CEL"

works fine for me. It should get all the nodes under the PARENT node a169fc91-9a45-11db-8c36-4fedb9902cf2 but only with name 20060919_tizio_test1.CEL. It retrieves exactly one node and it is ok.

On the contrary the following query:

+PARENT:"workspace://SpacesStore/a169fc91-9a45-11db-8c36-4fedb9902cf2" AND +@\{http\://www.alfresco.org/model/content/1.0\}name:'20060919_tizio_test1*"

does not work. It retrieves 0 nodes instead of 2. The difference between the 2 queries is that the second uses wildcard *. Is it wrong? Why?

I made thousands of test and I am going to become exhausted.

Please, help me with some explanations. I read the documentation but too examples and a lot of confusion.

All the best,

Sergio

[kevinr]

In Alfresco 1.4 you cannot use a wildcard within a quoted phrase "…" search, it is only applicable for tokenized searches - this feature has been added to Alfresco 2.0 as we have upgraded to the newer version of Lucene.

Thanks,

Kevin

[sergio]

Thank you Kevin.

So, how can I search all the nodes with their names (cm:name) starting with a specified string? Is not it possible in Alfresco 1.4?

What about the release 2.0? When will it be released to the community?

Thanks for your help.

Sergio

[andy]

Hi

As of 2.1, wild cards are supported in phrase queries in the repo but not currently via the UI.

Andy

[sergio]

Many thanks Andy.

[stebans]

Hi all,

I'm really lost with the search from web client and I have questions about the "Simple Search" (SS), "Advanced Search"(AS) and "Open Search" (OS) dialogs which produce confusing results.
Users do like OS and I want to make it clear before going any further.

First of all, I know that by default the search is carried out on "OR" operator and this can be changed by setting the <search-and-terms> to true. Unfortunately, an "OR" search remains in place when performing an Advanced Search against different "Categories". Is there a way to fine tune the search about categories where obviously this kind of “and searchâ€

[kevinr]

The search you mention: Nouveau Document
generates this:

TYPE:"{http://www.alfresco.org/model/content/1.0}content"  AND (+@\{http\://www.alfresco.org/model/content/1.0\}name:Nouveau +@\{http\://www.alfresco.org/model/content/1.0\}name:Document )
‍‍‍

because you have <search-and-terms> set TRUE. If you default to OR then it will generate:

TYPE:"{http://www.alfresco.org/model/content/1.0}content"  AND (@\{http\://www.alfresco.org/model/content/1.0\}name:Nouveau @\{http\://www.alfresco.org/model/content/1.0\}name:Document )
‍‍‍

And if you quote the phrase it will generate:

TYPE:"{http://www.alfresco.org/model/content/1.0}content"  AND (@\{http\://www.alfresco.org/model/content/1.0\}name:'Nouveau Document" )
‍‍‍

This is correct. Open Search does not have the same facilities as the web-client search, but we hope to improve that in the future.

As far as AND categories go, I personally think that if you have <search-and-terms> set TRUE then it should also AND the category - so i think this is a bug. Please raise it in JIRA.

Thanks,

Kevin

[stebans]

Thanks again for your answer, Kevin.

Nevertheless, some questions remain : why would "Docu*" produce some results and not "Docum*"? Have some users come into that same weird behavior?

Why aren't explicit "AND" simply discarded from the simple search or open search as some users are used to trying logical operator out with other search engines?
Should I also put these two last issues in Jira?

All the best,
Stephane

[kevinr]

Nevertheless, some questions remain : why would "Docu*" produce some results and not "Docum*"? Have some users come into that same weird behavior?

I'm not the engineer who wrote the Lucene integration, but i believe that will be due to the Lucene parser tokenizing the word at that point i.e. it is stored as two tokens…?

Please raise anything in JIRA you feel is an issue/bug.

Thanks,

Kevin