: I am upgrading an index from Solr 3.6 to 4.2.0. : Everything has been picked up except for the old DateFields.
Just to be crystal clear: 1) 4.2 is alreayd over a year old. the current rleease of Solr is 4.8, and 4.9 will most likeley be available within a day or two 2) Even in 4.9, "solr.DateField" still exists -- it has been deprecated and removed from the example schema, and will not be supported in 5.0, but just because you are upgrading to 4.x doesn't mean you have to stop using solr.DateField if it currently works for you. : I read some posts that due to the "extra functionality" of the : TrieDateField you would need to re-index for those fields. It's not a question of "extra functionality" -- the internal representation of the dates in the index is completley different. : To avoid re-indexing I was trying to do a Partial Update : (http://solr.pl/en/2012/07/09/solr-4-0-partial-documents-update/), you can't use partial updates to work arround a problem like this -- partial updates only work if the stored values in the index can be read by solr, the modified by the update command, and then written back out. but upgrading from 3.6, and try to "trick" solr by changing a "solr.DateField" to a "solr.TrieDateField" just fundementally won't work. Solr' won't be able to correctly read the stored date fields to return them, let alone modify them and write them back to hte index. If you really can't re-index from scratch, and all of your fields are in fact stored in your 3.6 index, and you really wnat to switch to using TrieDateField, then your best option is to fetch every doc from your 3.6 solr instance (like you were doing with your partial updates approach but pull back every field) and then push each doc to a *new* 4.x instance you've setup with the updated schema.xml using TrieDateField. -Hoss http://www.lucidworks.com/
