Solr CopyField behavior strange when copying date type (solr.TrieDateField) to string type (solr.TextField)

1
votes

I am copying date field to string field(schema.xml) using: <copyField source="mydate" dest="mystr"/>

source and dest types are defined as:

<field name="mydate" type="solr.TrieDateField" indexed="true" stored="true"/>
<field name="mystr" type="solr.TextField" indexed="true" stored="true"  multiValued="true"/>

value of mydate is "2009-06-03T00:00:00Z"

I am expecting the same value in mystr, i.e.,"2009-06-03T00:00:00Z", but am getting a date in mystr in a different format. The value I get in mystr is "Wed Jun 03 00:00:00 UTC 2009".

I am running solr in solrcloud mode and have 2 nodes solr cluster. Moreover, this behavior occurs ONLY in solrcloud mode. This is working perfectly if I run solr as a single node.

I am looking for help to get the source date as it is (without format change) into mystr field.

I know I can achieve this by defining a separate string field and set value in DIH, but I am curious to know why the above copy not working as expected.

1
solr

1 Answers

0
votes

The core issue here is that the date field is already parsed by the time copyField happens. So, you are getting internal date representation expanded back into the text for the copy.

That should not be happening with the classic schema with "schemaless mode" disabled. And maybe that's why it does not happen in standalone version. And for SolrCloud, most likely the parsing into existing fields already happens before the object is sent around to different nodes. Then, individual nodes, actually do the copyField instructions. That's my hypothesis anyway, I did not look at the source that closely.

The solution would be to use an UpdateRequestProcessor (e.g. CloneFieldUpdateProcessorFactory), as that will definitely copy exactly what you sent it. And it can be combined with DIH if needed. Just be careful to read the manual version matching to your Solr version, as there were multiple ways to invoke the URPs, depending on what you are running.

You may also find interesting the Solr puzzle I did that is based on that premise as well (well, you know part of the answer already).