Thanks Hoss for your reply... yeah I thought so... and I don't think it's even possible to add the id field to the document missing it, right? Also because some of the fields are not stored and it is my understanding that it is one of the requirements to have the update query work... right?
But still I don't understand why it gives a result with no problems for some docs and it throws an error for others... For example now I re-run the query and it works fine... Does the Elevation component has anything to do with this? Diego On Thu, Jun 12, 2014 at 12:47 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : > set with the latest solr version. (Now we are running version 4.8 - the > : > current schema has a uniqueid field set, while it wasn't present in the > : > earlier versions. This unique field is unsurprisingly called "id" but > not > : > all the documents have it.) > > this is going to be the source of a lot of pain for you -- and is almost > certainly the source of your current error -- if you don't have a > uniqueKey field (which yes: must exist for every document) distributed > search is not going to work -- it's such a low level expectation, that > it's take nas a given in a lot of the code (because it is verified on > startup) and explains why you get an NPE from mergeIds instead o a more > "freindly" error message.... > > : >> "trace":"java.lang.NullPointerException\n\tat > : >> > org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:962)\n\tat > > : > The funny thing is that if I query the same collection on a different > term > : > it works fine... > > ...because differnet terms match differnet documents - so the problematic > docs w/o a uniqueKey aren't included. > > : > I then tried to isolate the core where the exception happens and it > seems > : > to be core 2. (this command in fact triggers the exception, while > checking > : > in other cores simply gives me back that numFound=0) > ... > : > but if I query directly the core (without sharding) I obtain the > results > : > with no problems: > > ...because in non-sharded queries there is no need to mergeIds, so solr > doesn't notice/care that some of the docs it's returning are missing the > uniqueKey field. > > > -Hoss > http://www.lucidworks.com/ >
