: > Maybe copy fields should be refactored to happen in a new, core, : update processor, so there is nothing special/awkward about them? It : seems they fit as part of what an update processor is all about, : augmenting/modifying incoming documents. : : Seems reasonable. : By default, the copyFields could be read from the schema for back : compat (and the fact that copyField does feel more natural in the : schema)
As someone who has written special case UpdateProcessors that clone field values, I agree that it would be handy to have a new generic "CopyFieldUpdateProcessor" but i'm not really on board the idea of it reading <copyField .. /> declarations by default. the ideas really serve differnet purposes... * as an UpdateProcessor it's something that can be adjusted/configured/overridden on a use cases basis - some request handlers could be confgured to use a processor chain that includes the CopyFieldUpdateProcessor and some could be configured not to. * schema copyField declarations are things hat happen to *every* document, regardless of where it comes from. the use cases would be very differnet: consider a schema with many differnet fields specific to certain types of documents, as well as a few required fields that every type of document must have: "title", "description", "body", and "maintext" fields. it might make sense for to use differnet processor chains along with a CopyFieldUpdateProcessor to clone some some other fields (say: an "dust_jacked_text" field for books, and a "plot_summary" field for movies) into the "description" field when those docs are indexed -- but if you absolutely positively *allways* wanted the contents of title, description, and body to be copied into the "maintext" field that would make more sense as a schema.xml declaration. likewise: it would be handy t have an UpdateProcessor that rejected documents that were missing some fields -- but that would not be a true substitute for using required="true" on a field in the schema.xml. a single index may have multiple valid processor chains for differnet indexing situations -- but "rules" declared in the schema.xml are absolute and can not be circumvented. -Hoss
