t;> be in zip format.
> > >>> In any case, better to use the slightly later version -->
> > >>> SolrACLSecurity.java
> > >>> 26kb 12 Apr 2010 10:35
> > >>>
> > >>> Thanks,
> > >>> Peter
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Jul 30, 2012 at 7:50 PM, Sujatha Arun
> > >>> wrote:
> > >>>
> > >>> > I am uable to use the rar file from the site
> > >>> > https://issues.apache.org/jira/browse/SOLR-1872.
> > >>> >
> > >>> > When I try to open it,I get the message 'SolrACLSecurity.rar is not
> > RAR
> > >>> > archive.
> > >>> >
> > >>> > Is the file there at this link?
> > >>> >
> > >>> > Regards
> > >>> > Sujatha
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
to use the slightly later version -->
> >>> SolrACLSecurity.java
> >>> 26kb 12 Apr 2010 10:35
> >>>
> >>> Thanks,
> >>> Peter
> >>>
> >>>
> >>>
> >>> On Mon, Jul 30, 2012 at
>>>
>>> On Mon, Jul 30, 2012 at 7:50 PM, Sujatha Arun
>>> wrote:
>>>
>>> > I am uable to use the rar file from the site
>>> > https://issues.apache.org/jira/browse/SOLR-1872.
>>> >
>>> > When I try to open it,I get the message 'SolrACLSecurity.rar is not RAR
>>> > archive.
>>> >
>>> > Is the file there at this link?
>>> >
>>> > Regards
>>> > Sujatha
>>> >
>>>
>>
>>
>
>> On Mon, Jul 30, 2012 at 7:50 PM, Sujatha Arun
>> wrote:
>>
>> > I am uable to use the rar file from the site
>> > https://issues.apache.org/jira/browse/SOLR-1872.
>> >
>> > When I try to open it,I get the message 'SolrACLSecurity.rar is not RAR
>> > archive.
>> >
>> > Is the file there at this link?
>> >
>> > Regards
>> > Sujatha
>> >
>>
>
>
r version -->
> SolrACLSecurity.java
> 26kb 12 Apr 2010 10:35
>
> Thanks,
> Peter
>
>
>
> On Mon, Jul 30, 2012 at 7:50 PM, Sujatha Arun wrote:
>
> > I am uable to use the rar file from the site
> > https://issues.apache.org/jira/browse/SOLR-1872.
> >
> &g
he rar file from the site
> https://issues.apache.org/jira/browse/SOLR-1872.
>
> When I try to open it,I get the message 'SolrACLSecurity.rar is not RAR
> archive.
>
> Is the file there at this link?
>
> Regards
> Sujatha
>
looks like it might actually be a zip file. try renaming/unzipping it.
cheers,
rob
On Mon, Jul 30, 2012 at 2:50 PM, Sujatha Arun wrote:
> I am uable to use the rar file from the site
> https://issues.apache.org/jira/browse/SOLR-1872.
>
> When I try to open it,I get
I am uable to use the rar file from the site
https://issues.apache.org/jira/browse/SOLR-1872.
When I try to open it,I get the message 'SolrACLSecurity.rar is not RAR
archive.
Is the file there at this link?
Regards
Sujatha
Alexey ,
We are not planning to upgrade our solr version at the moment as all is fine
with the current version so far and hence would not be able to try this
solution .
Regards
Sujatha
On Fri, Jun 17, 2011 at 3:47 PM, Alexey Serba wrote:
> > Do you mean that we have current Index as it is an
Constantijn,
I am aware of this and we have already increased max boolean clauses to
<3500> from the default <1200> for all our 200+ instances .
But the requirement is that we could havenumber of products running
to several thousands for each of the instances and since is not defined
,
Thanks ,Peter .
This very much seems to be the solution that I should be going forward with
.Thanks for your time and clear explanation.
Regards
Sujatha
On Fri, Jun 17, 2011 at 2:49 PM, Peter Sturge wrote:
> You'll need to be a bit careful using joins, as the performance hit
> can be signi
> Do you mean that we have current Index as it is and have a separate core
> which has only the user-id ,product-id relation and at while querying ,do a
> join between the two cores based on the user-id.
Exactly. You can index user-id, product-id relation either to the same
core or to different c
Just to chip in my 2 cents:
You know you can increase the max number of boolean clauses in the
configuration files?
Depending on your situation it might not be a permanent fix, but it
could provide some instant relief.
Constantijn
On Fri, Jun 17, 2011 at 11:19 AM, Peter Sturge wrote:
> You'll
You'll need to be a bit careful using joins, as the performance hit
can be significant if you have lots of cross-referencing to do, which
I believe you would given your scenario.
Your table could be setup to use the username as the key (for fast
lookup), then map these to your own data class or co
Alexey,
Do you mean that we have current Index as it is and have a separate core
which has only the user-id ,product-id relation and at while querying ,do a
join between the two cores based on the user-id.
This would involve us to Index/delete the product as and when the user
subscription for
rs/results will be processed for a given search request
> (SOLR-1872 reads an acl file to populate such a list). So if you had
> 500 users who had purchased stuff at a given moment, you'd have 500
> entries in the table that hold the relevant data to filter/not filter
> searches/r
> So a search for a product once the user logs in and searches for only the
> products that he has access to Will translate to something like this . ,the
> product ids are obtained form the db for a particular user and can run
> into n number.
>
> &fq=product_id(100 10001 ..n number)
>
> b
Hi,
By in-memory, I mean you hold a list of users (+ some other parameters
like order number, expiry, what ever else you need) in one of those
Greek HashMaps, and use this list to determine what query
parameters/results will be processed for a given search request
(SOLR-1872 reads an acl file to
me ,would be great .I would also try to dig
deep into JAVA.
What s meant by in-memory?Is it the Ram memory ,So If i have
concurrent users ,each having products subscrbed,what would be the
Impact on memory ?
Regards
Sujatha
On Tue, Jun 14, 2011 at 5:43 PM, Peter Sturge wrote:
> SOLR-1
SOLR-1872 doesn't add discrete booleans to the query, it does it
programmatically, so you shouldn't see this problem. (if you have a
look at the code, you'll see how it filters queries)
I suppose you could modify SOLR-1872 to use an in-memory,
dynamically-updated user list (+ ass
Thanks Peter , for your input .
I really would like a document and schema agnostic solution as in solr
1872.
Am I right in my assumption that SOLR1872 is same as the solution that
we currently have where we add a flter query of the products to orignal
query and hence (SOLR 1872) will
Hi,
SOLR-1834 is good when the original documents' ACL is accessible.
SOLR-1872 is good where the usernames are persistent - neither of
these really fit your use case.
It sounds like you need more of an 'in-memory', transient access
control mechanism. Does the access have to e
s to site and purchases a product .
Given the 2 solutions above as SOLR -1872 where we have to specify the user
in an ACL file and
query for allow and deny also translates to what we are trying to do above
In Case of SOLR 1834 ,we are required to use a crawler (APACHE manifoldCF)
for indexing
23 matches
Mail list logo
