suja.a...@gmail.com
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
/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
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
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 suja.a...@gmail.com 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
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
later version --
SolrACLSecurity.java
26kb 12 Apr 2010 10:35
Thanks,
Peter
On Mon, Jul 30, 2012 at 7:50 PM, Sujatha Arun suja.a...@gmail.com 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
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
/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
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
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
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
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 peter.stu...@gmail.comwrote:
You'll need to be a bit careful using joins, as the
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 have n number of products running
to several thousands for each of the instances and since n is not defined
,
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 ase...@gmail.com wrote:
Do you mean that we have current
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.
search term fq=product_id(100 10001 ..n number)
parameters/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/results.
This won't
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
...@gmail.comwrote:
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
who
comes 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
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 exist beyond
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
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 (+ associated filters
22 matches
Mail list logo
