Please see the documentation:
http://wiki.apache.org/solr/SolrCloud#Required_Config
schema.xml
You must have a _version_ field defined:
field name=_version_ type=long indexed=true stored=true/
On Apr 11, 2012, at 9:10 AM, Benson Margulies wrote:
I didn't have a _version_ field, since
On Thu, Apr 12, 2012 at 11:56 AM, Mark Miller markrmil...@gmail.com wrote:
Please see the documentation:
http://wiki.apache.org/solr/SolrCloud#Required_Config
Did I fail to find this in google or did I just goad you into a writing job?
I'm inclined to write a JIRA asking for _version_ to be
google must not have found it - i put that in a month or so ago I believe -
at least weeks. As you can see, there is still a bit to fill in, but it
covers the high level. I'd like to add example snippets for the rest soon.
On Thu, Apr 12, 2012 at 12:04 PM, Benson Margulies
: Please see the documentation:
http://wiki.apache.org/solr/SolrCloud#Required_Config
:
: schema.xml
:
: You must have a _version_ field defined:
:
: field name=_version_ type=long indexed=true stored=true/
Seems like this is the kind of thing that should make Solr fail hard and
fast on
I think someone already made a JIRA issue like that. I think Yonik might
have had an opinion about it that I cannot remember right now.
On Thu, Apr 12, 2012 at 2:21 PM, Chris Hostetter
hossman_luc...@fucit.orgwrote:
: Please see the documentation:
On Thu, Apr 12, 2012 at 2:21 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: Please see the documentation:
http://wiki.apache.org/solr/SolrCloud#Required_Config :
: schema.xml
:
: You must have a _version_ field defined:
:
: field name=_version_ type=long indexed=true stored=true/
: Off the top of my head:
: _version_ is needed for solr cloud where a leader forwards updates to
: replicas, unless you're handing update distribution yourself or
: providing pre-built shards.
: _version_ is needed for realtime-get and optimistic locking
:
: We should document for sure... but
I'm probably confused, but it seems to me that the case I hit does not
meet any of Yonik's criteria.
I have no replicas. I'm running SolrCloud in the simple mode where
each doc ends up in exactly one place.
I think that it's just a bug that the code refuses to do the local
deletion when there's
On Thu, Apr 12, 2012 at 2:14 PM, Mark Miller markrmil...@gmail.com wrote:
google must not have found it - i put that in a month or so ago I believe -
at least weeks. As you can see, there is still a bit to fill in, but it
covers the high level. I'd like to add example snippets for the rest
Hard to say why its not working for you. Start with a fresh Solr and
work forward from there or back out your configs and plugins until it
works again.
On Tue, 2012-04-10 at 17:15 -0400, Benson Margulies wrote:
In my cloud configuration, if I push
delete
query*:*/query
/delete
followed
See https://issues.apache.org/jira/browse/SOLR-3347. I can replace the
solrconfig.xml with the vanilla solrconfig.xml and the problem
remains.
On Wed, Apr 11, 2012 at 6:35 AM, Darren Govoni dar...@ontrenet.com wrote:
Hard to say why its not working for you. Start with a fresh Solr and
work
I didn't have a _version_ field, since nothing in the schema says that
it's required!
On Wed, Apr 11, 2012 at 6:35 AM, Darren Govoni dar...@ontrenet.com wrote:
Hard to say why its not working for you. Start with a fresh Solr and
work forward from there or back out your configs and plugins until
In my cloud configuration, if I push
delete
query*:*/query
/delete
followed by:
commit/
I get no errors, the log looks happy enough, but the documents remain
in the index, visible to /query.
Here's what seems my relevant bit of solrconfig.xml. My URP only
implements processAdd.
13 matches
Mail list logo
