Hi Shawn/Jan, On Sun, Sep 25, 2016 at 6:18 PM, Shawn Heisey <apa...@elyograg.org> wrote:
> On 9/25/2016 4:24 AM, xavi jmlucjav wrote: > > Everything went well, no errors when solr restarted, the collections > shows > > the right number of docs. But when I try to run a query, I get: > > > > null:java.lang.NullPointerException > > Did you change any of the fieldType class values as you adjusted the > schema for the upgrade? A number of classes that were valid and > deprecated in 3.6 and 4.x were completely removed by 5.x, and 6.x > probably removed a few more. > Yes, I had to change some fields, basically to use TrieIntField etc instead of the old IntField. I was assuming by using the IndexUpgrader to upgrade the data to 6.1, the older IntField would work with the new TrieIntField. But I have tried loading the upgraded data into a standalone 6.1 and I am hitting the same issue, so this is not related to _version_ field (more on that below). Forget about solrcloud for now, having an old 3.6 index, should it be possible to use IndexUpgrader and load it on 6.1? How would one need to handle IntFields etc? > > If you did make changes like this to your schema, then what's in the > index will no longer match the schema, and the *only* option is a > reindex. Exceptions are likely if you don't reindex after schema > changes to the class value(s) or the index analyzer(s). > > Regarding the _version_ field: SolrCloud expects this field to be in > your schema. It might also expect that that every document in the index > will already contain a value in this field. Adding _version_ to your > schema should be treated similarly to the changes mentioned above -- a > reindex is required for proper operation. > > Even if the schema didn't change in a way that *requires* a reindex ... > the number of changes to the analysis components across three major > version jumps is quite large. Solr might not work as expected because > of those changes unless you reindex, even if you don't see any > exceptions. Changes to your schema because of changes in analysis > component behavior might be required -- which is another situation that > usually requires a reindex. > > Because of these potential problems, I always start a new Solr version > with no index data and completely rebuild my indexes after an upgrade. > That is the best way to ensure success. > I am totally aware of all the advantages of reindexing, sure. And that is what I always do, this time thought, seems the original data is not available... > You referenced a mailing list thread where somebody had success > converting non-cloud to cloud... but that was on version 4.8.1, two > major versions back from the version you're running. They also did not > upgrade major versions -- from some things they said at the beginning of > the thread, I know that the source version was at least 4.4. The thread > didn't mention any schema changes, either. > > If the schema doesn't change at all, moving from non-cloud to cloud is > very possible, but if the schema changes, the index data might not match > the schema any more, and that situation will not work. > Since you jumped three major versions, it's almost guaranteed that your > schema *did* change, and the changes may have been more extensive than > just adding the _version_ field. > > It's possible that there's a problem when converting a non-cloud install > with no _version_ field to a cloud install where the only schema change > is adding the _version_ field. We can treat THAT situation as a bug, > but if there are other schema changes besides adding _version_, the > exception you encountered is most likely not a bug. > The are two orthogonal issues here: A. moving to solrcloud from standalone without reindexing. And without having a _version_ field already indexed, of course. Is this even possible? >From the thread above, I understood it was possible, but you say that solrcloud expects _version_ to be there, with values, so this makes this move totally impossible without a reindexing. This should be made clear somewhere in the doc. I understand it is not a frequent scenario, but will be a deal breaker when it happens. So far the only thing I found is the aforementioned thread, that if I am not misreading, makes it sound as it will work ok. B. upgrading from a very old 3.6 version to 6.1 without reindexing: it seems like I am hitting an issue with this first. Even if this was resolved, I would not be able to achieve my goal due A, but would be good to know how to get this done too, if possible. Jan: I tried tweaking luceneMatchVersion too, no luck though. xavier > > Thanks, > Shawn > >
