Thanks Shawn, I understand that changing id to to string is not an option. I have a limitation that our Solr cluster is "live" during full indexing. We have many updates and the index is incrementally updated. There's no way to index everything on a side index and replace. So, I'm trying to find a solution where users can still work not depending on my full indexing. We have a periodic indexing job that runs once in a few weeks.
I thought about another option: 1. Add a new field - "id_str". 2. Let periodic full indexing run. 3. Somewhere later during full change the uniqeKey from my "id" to "id_str". May this work? Assuming that all ids are unique? On Thu, Mar 9, 2017 at 5:14 PM, Shawn Heisey <apa...@elyograg.org> wrote: > On 3/9/2017 4:20 AM, danny teichthal wrote: > > I have an "id" field that is defined on schema.xml with type long. > > For some use cases the id that is indexed exceeds Max long limitation. > > I thought about solving it by changing the id to type string. > > > > For my surprise, by only changing the definition on schema.xml and > > restarting Solr, I was able to read documents and update without the need > > to re-index. > > In general, changing the class used for a field won't work without a > reindex. You'll probably find that queries don't work to find the old > documents, even if Solr is able to correctly show the field in results. > I am very surprised that *anything* works with that change and an > existing index. > > If "id" is your uniqueKey and you are relying on Solr's ability to > replace existing documents using that field, you'll likely discover that > reindexing existing documents will result in duplicates instead of > deleting the old one. > > Thanks, > Shawn > >
