context:
> http://lucene.472066.n3.nabble.com/Solr-large-boolean-filter-tp4070747p4179276.html
> Sent from the Solr - User mailing list archive at Nabble.com.
Hello,
We have a similar requirement where a large list of IDs needs to be sent to
SOLR in filter query.
Could someone please help understand if this feature is now supported in the
new versions of SOLR?
Thanks
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-large
OK, thank you Otis, I *think* this should be easy to add - I can try. We
were calling them 'private library' searches
roman
On Mon, Jul 8, 2013 at 11:58 PM, Otis Gospodnetic <
otis.gospodne...@gmail.com> wrote:
> Hi Roman,
>
> I referred to something I called ""server-side named filters". It
>
Hi Roman,
I referred to something I called ""server-side named filters". It
matches the feature described at
http://www.elasticsearch.org/blog/terms-filter-lookup/
Would be a cool addition, IMHO.
Otis
--
Solr & ElasticSearch Support -- http://sematext.com/
Performance Monitoring -- http://semat
Roman,
It's covered in http://wiki.apache.org/solr/ContentStream
| For POST requests where the content-type is not
"application/x-www-form-urlencoded", the raw POST body is passed as a
stream.
So, there is no need for encoding of binary data inside the body.
Regarding encoding, I have a pos
Hello Mikhail,
Yes, GET is limited, but POST is not - so I just wanted that it works in
both the same way. But I am not sure if I am understanding your question
completely. Could you elaborate on the parameters/body part? Is there no
need for encoding of binary data inside the body? Or do you mean
Hello Roman,
Don't you consider to pass long id sequence as body and access internally
in solr as a content stream? It makes base64 compression not necessary.
AFAIK url length is limited somehow, anyway.
On Tue, Jul 2, 2013 at 9:32 PM, Roman Chyla wrote:
> Wrong link to the parser, should be:
Wrong link to the parser, should be:
https://github.com/romanchyla/montysolr/blob/master/contrib/adsabs/src/java/org/apache/solr/search/BitSetQParserPlugin.java
On Tue, Jul 2, 2013 at 1:25 PM, Roman Chyla wrote:
> Hello @,
>
> This thread 'kicked' me into finishing som long-past task of
> sendi
Hello @,
This thread 'kicked' me into finishing som long-past task of
sending/receiving large boolean (bitset) filter. We have been using bitsets
with solr before, but now I sat down and wrote it as a qparser. The use
cases, as you have discussed are:
- necessity to send lng list of ids as a
Not necessarily. If the auth tokens are available on some
other system (DB, LDAP, whatever), one could get them
in the PostFilter and cache them somewhere since,
presumably, they wouldn't be changing all that often. Or
use a UserCache and get notified whenever a new searcher
was opened and regenera
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
--
S
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
wrote:
> Btw.
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 R
On Mon, Jun 17, 2013 at 12:35 PM, Igor Kustov 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
i
Filter("id",idsList.toArray())
> // first problem id is just an int in my case, but this seems like the only
> normal constructor
>return new FilteredQuery(new BooleanQuery(), filter);
> // my goal here is to get only filtered data, but does BooleanQuery()
> equals
seems like the only
normal constructor
return new FilteredQuery(new BooleanQuery(), filter);
// my goal here is to get only filtered data, but does BooleanQuery() equals
to *:*?
}
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-large-boolean-filt
Krupansky
-Original Message-
From: Igor Kustov
Sent: Monday, June 17, 2013 6:52 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr large boolean filter
Where do the long list of IDs come from?
I'm indexing database, so the id list is security access control list.
--
View this mes
> Where do the long list of IDs come from?
I'm indexing database, so the id list is security access control list.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-large-boolean-filter-tp4070747p4070964.html
Sent from the Solr - User mailing list archive at Nabble.com.
y, June 15, 2013 6:49 PM
To: solr-user@lucene.apache.org
Subject: Solr large boolean filter
I know i'm not the first one with this problem.
I'm currently using solr 4.2.1 with approximately 10 mln documents in the
index.
The index is updated frequently.
The filter_query is just a one big
o improve this query performance.
>
> It doesn't seem like solr join could be applied there.
>
> Another option that I found is to somehow use Lucene FieldCacheTermsFilter.
> Does it worth a try?
>
> Maybe i've missed some other options?
>
>
>
>
>
>
ays to improve this query performance.
It doesn't seem like solr join could be applied there.
Another option that I found is to somehow use Lucene FieldCacheTermsFilter.
Does it worth a try?
Maybe i've missed some other options?
--
View this message in context:
http://lucene.472066.n3.n
21 matches
Mail list logo
