lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: additive params
Date Fri, 08 Sep 2006 21:52:52 GMT
: > The main use case is to allow configuration of a requestHandler that the
: > clients don't have to be aware of at all it "just works" ..
:
: That sounds fine then for things that are optinally appended, but not
: being able to override that doesn't make sense unless it's for some
: security purpose.

But if i'm the onwer of the index shouldn't that be my decision?  if i
want people to be able to have free reign over my index, i'll do this...

  <requestHandler name="dismax" class="solr.DisMaxRequestHandler" />

...now they can specify anything they want.  if i want to give them
helpful defaults to make their life easy, i can do this...

  <requestHandler name="easy" class="solr.DisMaxRequestHandler" >
    <lst name="defaults">
     <float name="tie">0.01</float>
     <str name="qf">text^0.5 features^1.0 name^1.2 sku^1.5</str>
     <str name="pf">text^0.2 features^1.1 name^1.5 manu^1</str>
     <str name="bf">ord(poplarity)^0.5</str>
     <str name="fq">inStock:true</str>
    </lst>
   </requestHandler>

...and they can use it as is, or "tweak" any of the params at query time.

If i have a client that says "i want and easy way to search all the
products that people can buy, and i need to let the user add options to
filter by price" i can setup this for them...

  <requestHandler name="buyable" class="solr.DisMaxRequestHandler" >
    <lst name="defaults">
     <float name="tie">0.01</float>
     <str name="qf">text^0.5 features^1.0 name^1.2 sku^1.5</str>
     <str name="pf">text^0.2 features^1.1 name^1.5 manu^1</str>
     <str name="bf">ord(poplarity)^0.5</str>
    </lst>
    <lst name="append">
     <str name="fq">inStock:true</str>
    </lst>
   </requestHandler>

...and tell them "use '/select/?qt=buyable&q=userinput' if the user wants
to filter on price add '&fq=price:[A TO B]'".

If i don't have the "append" params option, then i have to tell the client
"if you want to filter on price, you'll have to put '&fq=inStock:true' in
every request" at which point they now have to know something they didn't
know before (that there are products in the index which aren't for in
stock and thus not for sale) and they have to do something they don't want
to have to mess with (putting an extra parameter in)

If i want to change my index later by adding a new field of "forSale"
(independent of "inStock"; maybe our biz model now allows us to stock up
on products that we don't want to sell, or stat doing pre-sell products
that we don't have in stock yet) I need to go to all of my clients using
qt=buyable and say "remember that rule i told you about putting
'&fq=inStock:true' in the request whenever you filtered, you need to
change your code to use '&fq=forSale:true'" ... that's not neccessary with
"appended" init params, becuase i can just change the solrconfig.

: Although inStock:true makes sense as a default, it doesn't make sense
: not being able to ask about all items or items that aren't in stock if
: you need to.  The convenience of not having to know about some of the
: params (and providing them by default), is much different than locking
: things down by always adding those params.

that's the bueaty of being able to configure the same request handler in
the solrconfig more then once with different names -- the person
configuring the index can provide multiple options.  In my example above,
the "dismax" instance, the "easy" instance and the "buyable" instance can
all coexist in harmony.  If a client wants defaults but wants to be able
ot override them -- they can do that (as long as the index owner
configures it that way).

: Parameters that must always be appended seem to be the exception
: rather than the rule.
: But if that's the only mechanism to provide good defaults for
: appendable lists, people might use it and unnecessarily lock down the
: view of their data, even if it's not what they *really* meant to do.

why would it be the only mechanism? ... i'm not suggesting we get rid of
defaults, i'm suggesting we add another way to specify "default-ish"
params that get added to what is currently used (regardless of whether
what's currently being used comes from a default or a query param)

: Does that make sense (putting the power in the index config) for
: anything other than security filters?

the instock vs forsale example i gave above isn't really a security issue
as much as it is a "changing partition" issue ... currently the data is
partitioned one way (instock true or false) and in the future it might be
partitioned in another way (forsale true or false) and we want to be able
to change it without are clients needing to know.

the boosting example i gave in my last message also isn't really about
security -- it's about imposing biz rules on scoring that can be augmented
by user options but nevercompletley overridden.

: Security filters would normally be added at a higher level based on
: user-id or something, *or* could be based on custom logic in a custom
: request handler.

hey wait a minute, ithought i was the guy allways arguing that people
should just write their own request handlers? :) ... if you have complex
rules (security or otherwise) that require your own custom request handler
then by all means people should write them ... but this seems like a
pretty strait forward way to let people get more power out of the existing
handlers through configuration.



-Hoss


Mime
View raw message