Hello Oleg,
On Wed, Jul 17, 2013 at 3:49 PM, Oleg Burlaca wrote:
> Hello Roman and all,
>
> > sorry, haven't the previous thread in its entirety, but few weeks back
> that
> > Yonik's proposal got implemented, it seems ;)
>
> http://search-lucene.com/m/Fa3Dg14mqoj/bitset&subj=Re+Solr+large+bool
Hello Roman and all,
> sorry, haven't the previous thread in its entirety, but few weeks back
that
> Yonik's proposal got implemented, it seems ;)
http://search-lucene.com/m/Fa3Dg14mqoj/bitset&subj=Re+Solr+large+boolean+filter
In that post I see a reference to your plugin BitSetQParserPlugin, rig
Roman:
I think that SOLR-1913 is completely different. It's
about having a field in a document and being able
to do bitwise operations on it. So say I have a
field in a Solr doc with the value 6 in it. I can then
form a query like
{!bitwise field=myfield op=AND source=2}
and it would match.
You'r
Erick,
I wasn't sure this issue is important, so I wanted first solicit some
feedback. You and Otis expressed interest, and I could create the JIRA -
however, as Alexandre, points out, the SOLR-1913 seems similar (actually,
closer to the Otis request to have the elasticsearch named filter) but the
Is that this one: https://issues.apache.org/jira/browse/SOLR-1913 ?
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
Roman:
Did this ever make into a JIRA? Somehow I missed it if it did, and this would
be pretty cool
Erick
On Mon, Jul 15, 2013 at 6:52 PM, Roman Chyla wrote:
> On Sun, Jul 14, 2013 at 1:45 PM, Oleg Burlaca wrote:
>
>> Hello Erick,
>>
>> > Join performance is most sensitive to the number of
On Sun, Jul 14, 2013 at 1:45 PM, Oleg Burlaca wrote:
> Hello Erick,
>
> > Join performance is most sensitive to the number of values
> > in the field being joined on. So if you have lots and lots of
> > distinct values in the corpus, join performance will be affected.
> Yep, we have a list of uni
Hello Erick,
> Join performance is most sensitive to the number of values
> in the field being joined on. So if you have lots and lots of
> distinct values in the corpus, join performance will be affected.
Yep, we have a list of unique Id's that we get by first searching for
records
where loggedIn
Hello Jack,
Thanks for so many links, my comments are below, I'll found a way to
rephrase all my questions in one:
How to implement a DAC (Discretionary Access Control) similar to Windows OS
using SOLR?
What we have: a hierarchical filesystem, user and groups, permissions
applied at the level of
Join performance is most sensitive to the number of values
in the field being joined on. So if you have lots and lots of
distinct values in the corpus, join performance will be affected.
bq: I suppose the delete/reindex approach will not change soon
There is ongoing work (search the JIRA for "Sta
Take a look at LucidWorks Search and its access control:
http://docs.lucidworks.com/display/help/Search+Filters+for+Access+Control
Role-based security is an easier nut to crack.
Karl Wright of ManifoldCF had a Solr patch for document access control at
one point:
SOLR-1895 - ManifoldCF SearchCom
11 matches
Mail list logo
