09-22-2016 10:39 PM
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?
09-26-2016 04:05 AM
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).
09-23-2016 01:51 PM
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.
09-25-2016 07:24 AM
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.
09-26-2016 04:05 AM
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).
09-27-2016 10:25 AM
Thank you Axel for the answer.
Tags
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.