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)

Reply via email to