View Single Post
Old 08-06-2012, 03:40 AM   #6
chaley
Grand Sorcerer
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: 11,742
Karma: 6997045
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
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