The reasons we want to have different collections is that each of the
collections have different fields, and that some collections will contain
information that are more sensitive than others.
As such, we may need to restrict access to certain collections for some
users. Although the restriction w
I've tried to use, and there's still no suggestions returned even when I
used suggest.q.
Here is the log:
INFO - 2015-06-07 22:18:24.195; [collection1 shard1 core_node1
collection1] org.apache.solr.handler.component.SuggestComponent;
SuggestComponent prepare with :
suggest.count=10&suggest=true&
Yup indeed there's a lot less JSON.
But are we able to configure this somewhere permanently?
Normally I don't query the ZooKeeper in my URL directly for my query.
Regards,
Edwin
On 5 June 2015 at 21:04, Shawn Heisey wrote:
> On 6/5/2015 1:46 AM, Zheng Lin Edwin Yeo wrote:
> > That's why we ar
Hi,
I have a setup with AnalyzingInfixLookupFactory, suggest.count works. But
if I just replace:
s/AnalyzingInfixLookupFactory/BlendedInfixLookupFactory
suggest.count is not respected anymore, all suggestions are returned, so
making it virtually useless.
I am using RC4 that I believe is also bein
bq: we still need those information to be stored in a separate collection
for security reasons.
Not necessarily. I've seen lots of installations where "auth tokens" are
embedded in the document (say groups that can see this doc). Then
the front-end simply attaches &fq=auth_field:(groups each user
Please show us your configuration, and the queries you sent to Solr
along with at least enough of the output to see the problem.
I don't know why it would make a difference, but did you rebuild the
suggester after you changed the factory?
Best,
Erick
On Sun, Jun 7, 2015 at 8:49 AM, xavi jmlucjav
Check your solrconfig.xml
false
false
if you set to false then the Lookup data structure will rebuilt after the
commit.
You need to invoke the build command to build data for the suggester using
the command
* /suggesthandler?suggest.build=true *
On Sun, Jun 7, 2015 at 7:49 PM, Zheng Lin Edwin
Why don't we change the bin/run -d to have Common Daemons? This would be a
great enhancement to SOLR 5.x.
We would switch to this if it was integrated. We currently use RunIt. But
love Common Daemons.
http://smarden.org/runit/
http://commons.apache.org/proper/commons-daemon/
On Thu, Jun 4, 2015
https://issues.apache.org/jira/browse/SOLR-7644
On Sun, Jun 7, 2015 at 11:54 AM, William Bell wrote:
> Why don't we change the bin/run -d to have Common Daemons? This would be a
> great enhancement to SOLR 5.x.
>
> We would switch to this if it was integrated. We currently use RunIt. But
> love
So I've been trying to utilize Solr, and I integrated with Solr 4.x but
using its war file. I wanted to use a dependency management tool so it was
easier to migrate between versions. I've read several blogs on how to
integrate Solr with other dependency management tools and they all use the
war f
Here is a weird architecture...
We have a SOLR Master today, next to our database in our local data center.
We do Solr replication to Amazon East and West coasts once the index is
completed.
We would like to deploy Solr Cloud while leaving the master in place.
1. Local has SQL Server, and Solr M
Solr 5 _does_ distribute a war file so this shouldn't be a blocker short-term.
Look in /server/webapps/solr.war. So there's no (short term) reason
why it "must run on jetty". The _scripts_ use jetty but if you don't use
the scripts
Here's a useful Wiki page with the current state of affair
Bill:
We're working on CDCR, Cross Data Center Replication, see:
https://issues.apache.org/jira/browse/SOLR-6273
Not entirely sure this pertains, but it might be something that's useful
in this situation. Essentially you'd have two separate clusters, one
East and one West. This is "active passive
Thanks Erick. Just to clarify I don't have to have a war file. And while
a war file makes moving between 4.x -> 5.x somewhat smoother it's really
about being able to use dependency management tools to manage whatever that
binary is. The only problem is to get that 5.x war file you can't get it
t
I would run two independent Solr Cloud clusters and send the data to them
reliably through something like Amazon SQS.
Splitting a Zookeeper ensemble across two regions (or AZs) makes a single point
of failure. One region will have the majority, and if that fails, you’re dead.
If you split acros
: I was hoping there was a solr server dependency package that I could
: declare against to get solr's standalone server which seems to be the
: direction the team is taking, and I want to stay in those lines for the
: future if that's the direction.
it's hard to understand what exactly your ulti
07 June 2015, Apache Solr™ 5.2 available
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search, dynamic clustering, database
integration, rich document (e.g., Word,
On 30 May 2015 12:08, "Lalit Kumar 4" wrote:
> Please unsubscribe me as well
>
> On May 30, 2015 15:23, Neha Jatav wrote:
> Unsubscribe me
>
18 matches
Mail list logo
