What I think I'm seeing is two validation options: 1. Set the "updateable" fields explicitly in the schema. <field name="name" type="text" updateable="true" indexed="true" stored="true"/>
* throw an exception at startup if an updateable field is not stored. If somewhere down the road we figure out how to efficiently handled unstored fields, we can remove this error. * when 'updating', only copy the fields marked 'updateable' * If someone sends an 'update' request and there are no fields marked updateable, return an error 2. Assume all stored fields that are not copied to are 'updateable' * return an error if someone sends an 'update' request and there are no stored fields I vote for option #1 -- although most configurations that want to 'update' fields will probably mark all stored fields as 'updateable', it seems valuable to make the schema designer explicitly specify what will happen on an 'update' - - - - - - - Is there a better word then 'update'? It seems there is already enough confusion between UpdateHandlers, "Update Plugins", UpdateRequestHandler etc. In this case "update" makes sense as it is the SQL equivolent. - - - - - - - I have something working that adds a 'mode' to AddUpdateCommand. The modes I need are: REPLACE_DOCUMENT REPLACE_FIELDS REPLACE_DISTINCT_FIELDS ADD_FIELDS ADD_DISTINCT_FIELDS ryan
