cancel
Showing results for 
Search instead for 
Did you mean: 

Search repository nodes in Alfresco.

mpjoker_java
Champ in-the-making
Champ in-the-making

Used: Enterprise 5.1.1 + solr 4.10.3
Problem:
query:
... @cm\:name:"#*2016-6*" ...
the result: // does not contain a complete list of entries
- ... 2016-60 ...
- ... 2016-6  ...
- ... 2016-65 ...
- ... 2016-66 ...
if adding a parameter - locale=en, the result
- ... 2016-60 ...
- ... 2016-6  ...

When specify request
... @cm\:name:"#*2016-61*" ...
result:
- ... 2016-61 ...

To re-index is not correct the state.
On the local machine does not have such trouble.

Suggest what parameters affect the results?
How can I fix the results obtained?

1 ACCEPTED ANSWER

afaust
Legendary Innovator
Legendary Innovator

You can use that property in keywords or in a special field of the advanced search form.

Differences between localhost and server can be explained by potentially different locales on the nodes as well as for the Repository server JVM (which can influence locales on nodes as well as during search).

View answer in original post

4 REPLIES 4

afaust
Legendary Innovator
Legendary Innovator

Can you provide a bit more information about how you are executing that search (in JavaScript or in the Node Browser), and what other parameters you might be providing in the search. There are different APIs to execute a search and it is not clear which one you have used.

Also, it is not quite clear from your question what the full result set should be.

You are making extensive use of wildcards. This type of search can be very locale-dependent, which can partially be seen in the different result you get for en. The reason for this is the tokenisation of both the index data as well as the request data. If the tokenisation of both does not match up exactly, there may be some expected results that you are not getting. It is worth checking what locales the individual documents you are expected have been assigned. You can see this in the node browser as part of the node properties.

If you often have to search for a particular date-like fragment of the document name, I'd recommend extracting that fragment into its own property. This not only improves the performance of the search by potentially obsoleting the use of wildcards and limiting the search scope, it can also provide far more accurate results.

mpjoker_java
Champ in-the-making
Champ in-the-making

Thank you for your comments.
To query used different tools: the Node Browser (lucene), the JavaScript console (lucene, fts-alfresco) and /solr4/#/alfresco/query.
Another parameter in the query - clarifying the type of node (TYPE:"<existentType>" AND @cm\:name:"#*2016-6*").
Expected result:
- ... 2016-60 ...
- ... 2016-6 ...
- ... 2016-61 ...
- ... 2016-62 ...
- ... //full list records: 6, 60..69; all list of numbers are in the repository

Looked properties of nodes for the 2016-62, 2016-63 'sys:locale=ru'. Thanks to become more clear.

>>recommend extracting that fragment into its own property.
It is intended to use this property to the keywords?
The fact that this request is generated from the interface (share), to allow users to filter the existing nodes by name.

It remains unclear why different results on the localhost and on the server (version and settings for solr the same)?
On the localhost, this query returns the list of existing nodes by template, regardless of locale.

afaust
Legendary Innovator
Legendary Innovator

You can use that property in keywords or in a special field of the advanced search form.

Differences between localhost and server can be explained by potentially different locales on the nodes as well as for the Repository server JVM (which can influence locales on nodes as well as during search).

mpjoker_java
Champ in-the-making
Champ in-the-making

Thank you Axel for the answer.