Hi, The unfortunate thing about this is what you still have to *pass* that filter from the client to the server every time you want to use that filter. If that filter is big/long, passing that in all the time has some price that could be eliminated by using "server-side named filters".
Otis -- Solr & ElasticSearch Support http://sematext.com/ On Tue, Jun 18, 2013 at 8:16 AM, Erick Erickson <erickerick...@gmail.com> wrote: > You might consider "post filters". The idea > is to write a custom filter that gets applied > after all other filters etc. One use-case > here is exactly ACL lists, and can be quite > helpful if you're not doing *:* type queries. > > Best > Erick > > On Mon, Jun 17, 2013 at 5:12 PM, Otis Gospodnetic > <otis.gospodne...@gmail.com> wrote: >> Btw. ElasticSearch has a nice feature here. Not sure what it's >> called, but I call it "named filter". >> >> http://www.elasticsearch.org/blog/terms-filter-lookup/ >> >> Maybe that's what OP was after? >> >> Otis >> -- >> Solr & ElasticSearch Support >> http://sematext.com/ >> >> >> >> >> >> On Mon, Jun 17, 2013 at 4:59 PM, Alexandre Rafalovitch >> <arafa...@gmail.com> wrote: >>> On Mon, Jun 17, 2013 at 12:35 PM, Igor Kustov <ivkus...@gmail.com> wrote: >>>> So I'm using query like >>>> http://127.0.0.1:8080/solr/select?q=*:*&fq={!mqparser}id:%281%202%203%29 >>> >>> If the IDs are purely numeric, I wonder if the better way is to send a >>> bitset. So, bit 1 is on if ID:1 is included, bit 2000 is on if ID:2000 >>> is included. Even using URL-encoding rules, you can fit at least 65 >>> sequential ID flags per character and I am sure there are more >>> efficient encoding schemes for long empty sequences. >>> >>> Regards, >>> Alex. >>> >>> >>> >>> Personal website: http://www.outerthoughts.com/ >>> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch >>> - Time is the quality of nature that keeps events from happening all >>> at once. Lately, it doesn't seem to be working. (Anonymous - via GTD >>> book)