search suggestions select a different index than the one that gives results | Community
Skip to main content
lksfjhadfas
lksfjhadfas
New Participant
October 17, 2018
Solved

search suggestions select a different index than the one that gives results

  • October 17, 2018
  • 2 replies
  • 1511 views

Hello Everyone,

We have three indexes with each indexing different properties and they are working perfectly for normal querying. But when i use suggest query

SELECT [rep:suggest()] as suggestion FROM [nt:base] as s WHERE (ISDESCENDANTNODE(s,'/content/fai/us-products')) AND suggest('richard')

It selects another index which doesnt give any results. (It selects faiLiteratureIndex rather than faiManagerIndex).

Is there any way i can rank them?

cost for [/content/fai/oak:index/faiLiteratureIndex] of type (lucene-property) with plan [lucene:faiLiteratureIndex(/content/fai/oak:index/faiLiteratureIndex) *:*] is 2.00

cost for [/content/fai/oak:index/faiManagerIndex] of type (lucene-property) with plan [lucene:faiManagerIndex(/content/fai/oak:index/faiManagerIndex) *:*] is 2.00

cost for [/content/fai/oak:index/faiBaseIndex] of type (lucene-property) with plan [lucene:faiBaseIndex(/content/fai/oak:index/faiBaseIndex) *:*] is 2.00

cost for lucene-property[/content/fai/oak:index/faiLiteratureIndex] is 2.0

Just for info though i have useInSuggest in all the indexes for different  properties

Thank you!

~Swetha

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by Peter_Puzanovs

    Dear Swetha,

    Lucene indexes are calculated based on following formula:

    Estimated Entry Count  - num of docs

    Cost Per Execution - 0 //for local machine execution

    Cost Per Entry  // Lucene index format V1 == 1.5 V2 == 1.0

    Oak decides which index to use based on lowest execution cost. It  takes into account all matching indexes, it does not take into account user preference.

    In this case, you are getting a 'Tie' where 2 indexes have same price. The first one get's chosen.

    Please change your query, so that your preferred index get's better value, then the lower one. Alternatively, consider switching to Solr that provides much better support for both Suggestions and more indexing, search options in general. In Solr YOU decide which collection to use and how.

    We are seeing OAK, now re-implement what Solr has already achieved in a really interesting way with little to no options of inspecting what's inside each index and no tools to manipulate your index on the fly. Could we not go 1 step back and borrow good ideas from Solr/Elastic and bring them to Oak lucene indexing?

    Regards,

    Peter

    2 replies

    smacdonald2008
    smacdonald2008
    New Participant
    October 18, 2018

    Excellent reply Peter!

    Peter_Puzanovs
    Peter_PuzanovsAccepted solution
    New Participant
    October 18, 2018

    Dear Swetha,

    Lucene indexes are calculated based on following formula:

    Estimated Entry Count  - num of docs

    Cost Per Execution - 0 //for local machine execution

    Cost Per Entry  // Lucene index format V1 == 1.5 V2 == 1.0

    Oak decides which index to use based on lowest execution cost. It  takes into account all matching indexes, it does not take into account user preference.

    In this case, you are getting a 'Tie' where 2 indexes have same price. The first one get's chosen.

    Please change your query, so that your preferred index get's better value, then the lower one. Alternatively, consider switching to Solr that provides much better support for both Suggestions and more indexing, search options in general. In Solr YOU decide which collection to use and how.

    We are seeing OAK, now re-implement what Solr has already achieved in a really interesting way with little to no options of inspecting what's inside each index and no tools to manipulate your index on the fly. Could we not go 1 step back and borrow good ideas from Solr/Elastic and bring them to Oak lucene indexing?

    Regards,

    Peter

      Terms & ConditionsAccessibility statement

      Loading footer...