FAQ
Hi

Would like to get some advice on should the queries parameters be define
in Solr or let the clients applications define and pass the queries
parameters to Solr?

Regards,
Derek



----------------------
CONFIDENTIALITY NOTICE

This e-mail (including any attachments) may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please inform the sender immediately and delete this e-mail (including any attachments) from your computer, and you must not use, disclose to anyone else or copy this e-mail (including any attachments), whether in whole or in part.

This e-mail and any reply to it may be monitored for security, legal, regulatory compliance and/or other appropriate reasons.

Search Discussions

  • Emir Arnautovic at Jun 13, 2016 at 9:51 am
    Hi Derek,
    Maybe I am looking this from perspective who is working with other
    peoples' setups, but I prefer when it is defined in Solr configs: I can
    get sense of queries from looking at configs, you have mechanism to lock
    some parameters, updates are centralized... However, it does come with
    some cons: it is less expressive than what you can do in client code,
    you have to reload cores when you want to change, people tend to
    override it from client so you get configs in two places.

    HTH,
    Emir
    On 13.06.2016 05:21, Derek Poh wrote:
    Hi

    Would like to get some advice on should the queries parameters be
    define in Solr or let the clients applications define and pass the
    queries parameters to Solr?

    Regards,
    Derek



    ----------------------
    CONFIDENTIALITY NOTICE
    This e-mail (including any attachments) may contain confidential
    and/or privileged information. If you are not the intended recipient
    or have received this e-mail in error, please inform the sender
    immediately and delete this e-mail (including any attachments) from
    your computer, and you must not use, disclose to anyone else or copy
    this e-mail (including any attachments), whether in whole or in part.
    This e-mail and any reply to it may be monitored for security, legal,
    regulatory compliance and/or other appropriate reasons.
    --
    Monitoring * Alerting * Anomaly Detection * Centralized Log Management
    Solr & Elasticsearch Support * http://sematext.com/
  • Derek Poh at Jun 14, 2016 at 1:08 am
    Hi Emir

    Thank you for pointing out the cons of defining them in Solr config.

    One of the thing I am worry about in letting clientapplication defined
    the parametersis the developers will use or include unnecessary, wrong
    and resource intensive parameters.

    On 6/13/2016 5:50 PM, Emir Arnautovic wrote:
    Hi Derek,
    Maybe I am looking this from perspective who is working with other
    peoples' setups, but I prefer when it is defined in Solr configs: I
    can get sense of queries from looking at configs, you have mechanism
    to lock some parameters, updates are centralized... However, it does
    come with some cons: it is less expressive than what you can do in
    client code, you have to reload cores when you want to change, people
    tend to override it from client so you get configs in two places.

    HTH,
    Emir
    On 13.06.2016 05:21, Derek Poh wrote:
    Hi

    Would like to get some advice on should the queries parameters be
    define in Solr or let the clients applications define and pass the
    queries parameters to Solr?

    Regards,
    Derek



    ----------------------
    CONFIDENTIALITY NOTICE
    This e-mail (including any attachments) may contain confidential
    and/or privileged information. If you are not the intended recipient
    or have received this e-mail in error, please inform the sender
    immediately and delete this e-mail (including any attachments) from
    your computer, and you must not use, disclose to anyone else or copy
    this e-mail (including any attachments), whether in whole or in part.
    This e-mail and any reply to it may be monitored for security, legal,
    regulatory compliance and/or other appropriate reasons.

    ----------------------
    CONFIDENTIALITY NOTICE

    This e-mail (including any attachments) may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please inform the sender immediately and delete this e-mail (including any attachments) from your computer, and you must not use, disclose to anyone else or copy this e-mail (including any attachments), whether in whole or in part.

    This e-mail and any reply to it may be monitored for security, legal, regulatory compliance and/or other appropriate reasons.
  • Emir Arnautovic at Jun 14, 2016 at 8:12 am
    Hi Derek,
    Unless you lock all your parameters, there will always be a chance of
    inefficient queries. Only way to fight that is to have full control of
    Solr interface and provide some search API, or to do regular search log
    grooming.

    Emir
    On 14.06.2016 03:05, Derek Poh wrote:
    Hi Emir

    Thank you for pointing out the cons of defining them in Solr config.

    One of the thing I am worry about in letting clientapplication defined
    the parametersis the developers will use or include unnecessary, wrong
    and resource intensive parameters.

    On 6/13/2016 5:50 PM, Emir Arnautovic wrote:
    Hi Derek,
    Maybe I am looking this from perspective who is working with other
    peoples' setups, but I prefer when it is defined in Solr configs: I
    can get sense of queries from looking at configs, you have mechanism
    to lock some parameters, updates are centralized... However, it does
    come with some cons: it is less expressive than what you can do in
    client code, you have to reload cores when you want to change, people
    tend to override it from client so you get configs in two places.

    HTH,
    Emir
    On 13.06.2016 05:21, Derek Poh wrote:
    Hi

    Would like to get some advice on should the queries parameters be
    define in Solr or let the clients applications define and pass the
    queries parameters to Solr?

    Regards,
    Derek



    ----------------------
    CONFIDENTIALITY NOTICE
    This e-mail (including any attachments) may contain confidential
    and/or privileged information. If you are not the intended recipient
    or have received this e-mail in error, please inform the sender
    immediately and delete this e-mail (including any attachments) from
    your computer, and you must not use, disclose to anyone else or copy
    this e-mail (including any attachments), whether in whole or in part.
    This e-mail and any reply to it may be monitored for security,
    legal, regulatory compliance and/or other appropriate reasons.

    ----------------------
    CONFIDENTIALITY NOTICE
    This e-mail (including any attachments) may contain confidential
    and/or privileged information. If you are not the intended recipient
    or have received this e-mail in error, please inform the sender
    immediately and delete this e-mail (including any attachments) from
    your computer, and you must not use, disclose to anyone else or copy
    this e-mail (including any attachments), whether in whole or in part.
    This e-mail and any reply to it may be monitored for security, legal,
    regulatory compliance and/or other appropriate reasons.
    --
    Monitoring * Alerting * Anomaly Detection * Centralized Log Management
    Solr & Elasticsearch Support * http://sematext.com/
  • Derek Poh at Jun 15, 2016 at 12:23 am
    Hi Emir

    Yaguess one way is to implement a policy where new queries from client
    application have to be reviewcouple with periodic search log grooming as
    you have suggested.
    On 6/14/2016 4:12 PM, Emir Arnautovic wrote:
    Hi Derek,
    Unless you lock all your parameters, there will always be a chance of
    inefficient queries. Only way to fight that is to have full control of
    Solr interface and provide some search API, or to do regular search
    log grooming.

    Emir
    On 14.06.2016 03:05, Derek Poh wrote:
    Hi Emir

    Thank you for pointing out the cons of defining them in Solr config.

    One of the thing I am worry about in letting clientapplication
    defined the parametersis the developers will use or include
    unnecessary, wrong and resource intensive parameters.

    On 6/13/2016 5:50 PM, Emir Arnautovic wrote:
    Hi Derek,
    Maybe I am looking this from perspective who is working with other
    peoples' setups, but I prefer when it is defined in Solr configs: I
    can get sense of queries from looking at configs, you have mechanism
    to lock some parameters, updates are centralized... However, it does
    come with some cons: it is less expressive than what you can do in
    client code, you have to reload cores when you want to change,
    people tend to override it from client so you get configs in two
    places.

    HTH,
    Emir
    On 13.06.2016 05:21, Derek Poh wrote:
    Hi

    Would like to get some advice on should the queries parameters be
    define in Solr or let the clients applications define and pass the
    queries parameters to Solr?

    Regards,
    Derek



    ----------------------
    CONFIDENTIALITY NOTICE
    This e-mail (including any attachments) may contain confidential
    and/or privileged information. If you are not the intended
    recipient or have received this e-mail in error, please inform the
    sender immediately and delete this e-mail (including any
    attachments) from your computer, and you must not use, disclose to
    anyone else or copy this e-mail (including any attachments),
    whether in whole or in part.
    This e-mail and any reply to it may be monitored for security,
    legal, regulatory compliance and/or other appropriate reasons.

    ----------------------
    CONFIDENTIALITY NOTICE
    This e-mail (including any attachments) may contain confidential
    and/or privileged information. If you are not the intended recipient
    or have received this e-mail in error, please inform the sender
    immediately and delete this e-mail (including any attachments) from
    your computer, and you must not use, disclose to anyone else or copy
    this e-mail (including any attachments), whether in whole or in part.
    This e-mail and any reply to it may be monitored for security, legal,
    regulatory compliance and/or other appropriate reasons.

    ----------------------
    CONFIDENTIALITY NOTICE

    This e-mail (including any attachments) may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please inform the sender immediately and delete this e-mail (including any attachments) from your computer, and you must not use, disclose to anyone else or copy this e-mail (including any attachments), whether in whole or in part.

    This e-mail and any reply to it may be monitored for security, legal, regulatory compliance and/or other appropriate reasons.
  • Scott.chu at Jun 15, 2016 at 1:47 am
    In my case, I write a HTTP gateway between application and Solr engine. This is long existed before I use Solr as SE. Back that time, I figure out one day I might replace our old SE and it would cause two dilemma:
    1> If our applications directly call the API of THE search engines, when we replace it with another SE, all the calling statements have to be rewritten. It would be a very hard job for us, especially when the number and size of applications get bigger.
    2> We have applications written in different languages and we from time to time need to maunally test status of SE by our system engineers.
    Furthermore, we want to fix some default parameters in the gateway for simplicity and security issues (e.g. Shortening the size of HTTP call, Prevent db names, field names, etc. shown in the HTTP call, etc.)
    And these considerations ended up with a gateway design.

    For your question, IMHO, I wouldn't define query parameters in Solr unless you think they WOULD BE GLOBALIZED. You can consider our solution.


    scott.chu,scott.chu@udngroup.com
    2016/6/15 (週三)
    ----- Original Message -----
    From: Derek Poh
    To: solr-user
    CC:
    Date: 2016/6/13 (週一) 11:21
    Subject: Define search query parameters in Solr or let clients applicationscraft them?


    Hi

    Would like to get some advice on should the queries parameters be define
    in Solr or let the clients applications define and pass the queries
    parameters to Solr?

    Regards,
    Derek



    ----------------------
    CONFIDENTIALITY NOTICE

    This e-mail (including any attachments) may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please inform the sender immediately and delete this e-mail (including any attachments) from your computer, and you must not use, disclose to anyone else or copy this e-mail (including any attachments), whether in whole or in part.

    This e-mail and any reply to it may be monitored for security, legal, regulatory compliance and/or other appropriate reasons.


    -----
    未在此訊息中找到病毒。
    已透過 AVG 檢查 - www.avg.com
    版本: 2015.0.6201 / 病毒庫: 4598/12409 - 發佈日期: 06/12/16
  • Derek Poh at Jun 15, 2016 at 3:30 am
    Hi Scott, thank you for sharing your solution, appreciate it.

    To me interms of maintainability I think it will bebetter to define all
    the parameters either at the client end or solr end.
    On 6/15/2016 9:47 AM, scott.chu wrote:
    In my case, I write a HTTP gateway between application and Solr engine. This is long existed before I use Solr as SE. Back that time, I figure out one day I might replace our old SE and it would cause two dilemma:
    1> If our applications directly call the API of THE search engines, when we replace it with another SE, all the calling statements have to be rewritten. It would be a very hard job for us, especially when the number and size of applications get bigger.
    2> We have applications written in different languages and we from time to time need to maunally test status of SE by our system engineers.
    Furthermore, we want to fix some default parameters in the gateway for simplicity and security issues (e.g. Shortening the size of HTTP call, Prevent db names, field names, etc. shown in the HTTP call, etc.)
    And these considerations ended up with a gateway design.

    For your question, IMHO, I wouldn't define query parameters in Solr unless you think they WOULD BE GLOBALIZED. You can consider our solution.


    scott.chu,scott.chu@udngroup.com
    2016/6/15 (週三)
    ----- Original Message -----
    From: Derek Poh
    To: solr-user
    CC:
    Date: 2016/6/13 (週一) 11:21
    Subject: Define search query parameters in Solr or let clients applicationscraft them?


    Hi

    Would like to get some advice on should the queries parameters be define
    in Solr or let the clients applications define and pass the queries
    parameters to Solr?

    Regards,
    Derek



    ----------------------
    CONFIDENTIALITY NOTICE

    This e-mail (including any attachments) may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please inform the sender immediately and delete this e-mail (including any attachments) from your computer, and you must not use, disclose to anyone else or copy this e-mail (including any attachments), whether in whole or in part.

    This e-mail and any reply to it may be monitored for security, legal, regulatory compliance and/or other appropriate reasons.


    -----
    未在此訊息中找到病毒。
    已透過 AVG 檢查 - www.avg.com
    版本: 2015.0.6201 / 病毒庫: 4598/12409 - 發佈日期: 06/12/16

    ----------------------
    CONFIDENTIALITY NOTICE

    This e-mail (including any attachments) may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please inform the sender immediately and delete this e-mail (including any attachments) from your computer, and you must not use, disclose to anyone else or copy this e-mail (including any attachments), whether in whole or in part.

    This e-mail and any reply to it may be monitored for security, legal, regulatory compliance and/or other appropriate reasons.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsolr-user @
categorieslucene
postedJun 13, '16 at 3:24a
activeJun 15, '16 at 3:30a
posts7
users3
websitelucene.apache.org...

People

Translate

site design / logo © 2019 Grokbase