View Single Post
Old 08-06-2012, 03:40 AM   #6
chaley
"chaley", not "charley"
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 5,686
Karma: 1137958
Join Date: Jan 2010
Location: France
Device: Many android devices
Quote:
Originally Posted by _Em View Post
How come the import conversion works correctly? Could the same code be used for the search/replace?
No, at least not in a way that is maintainable. The import code is special cased and handles only pubdate. Search/replace must handle all fields of all types, custom or standard. It knows it has a source and destination field but doesn't care what the base types are; the cross-product of types make such knowledge impractical. Instead it uses metadata for the destination field to look up a db "setter" function for that field, then calls that function hoping that it can handle any necessary type conversion from the source type. There was a path where the pubdate setter did not do the conversion.

FWIW: there was also a path where S/R attempted to set the timestamp. This would never work, so timestamp is no longer a permitted destination field.
chaley is offline   Reply With Quote