: I agree. I started down that path, and it gets pretty ugly. I : stopped. I have opted for a syntax that 'updates' all stored fields, : but lets you say explicitly what to do for each field. If there is a : stored field you want to skip, you can specify that in command rather : then in the schema.
the schema creator should still have some say in what kinds of things are allowed/dissalloed though -- the person doing the "update" may not fully understand the underlying model. : > another simple approach would be to make "updatability" a property of the : > schema, that can contain a few different values... : This is an interisting idea, but (if i'm understaning your suggestion : correctly) it seems like TOO big of change from the existing schema. the schema.xml format wouldn't change much .. just a new attribute on the <schema> tag ... the existing example schema would either be labeled "loose" or "none" and we could provide another example of "strict" ... or we would label it "strict" and remove the refrences to indexed/stored and only mention them in comments describing other things you can do if you dont' require the ability to mutate documents. : think throwing an error if there are no stored fields is reasonable : and only updating stored fields is simple enough logic I don't think : we need to over complicate it. throwing an error if there are no stored fields in the schema, or no stored fields in the existing document, or no stored fields in mutate request? what if the document just doesn't have any stored fields because the first time it was added, the stored fields weren't known yet? what if the document does have stored fields, but it also has an indexed but not stored fields, and the person doing the update doesn't realize htat and doesn't send a replacement value for that field? : > another approach i don't really have fully fleshed out in my head would be : > to introduce a concept of "fieldsets" ... an update that : > sets/appends/incrments a field in a fieldset which does not provide a : : I may be working on this, but not sure if it is what you are saying. I have: no, i was thining of it as a new bit of syntax in the schema ... after defining all of your <field>s you have some <fieldset>s and any time you update a doc, and mutate a field (either overwrite, append, increment, whatever) which is in some <fieldset>s then you have to also provide a new value for any non-stored field also listed in those fieldset. in a simpel schema, you'd only need one <fieldset> and it would list every field (we'd probably even want a simple syntactic alias for that) but in more complex schemas where you want SOlr to provide some sanity checking on your docs, but you frequently have different "types" of docs in your schema with differnet sets of common overlapping fields - the <fieldset>s are your way of telling Solr when to complain. : public enum FieldMODE { : APPEND, // add the fields to existing fields : OVERWRITE, // overwrite existing fields : INCREMENT, // increment existing field. Must be a number! : DISTINCT, // same as APPEND, but make sure there are distinct values : IGNORE // ignore the previous value -- don't copy it as i understand it, these are options specified by the client triggering the "mutate doc" command right? ... they totally make sense, but they don't really address what Sol should do if the command doesn't mention a field which is in the schema. the use case i'm thinking about is an existing solr index with lots of clients from differnet parts of a company adding/mutating documents, and then the schema needs changed. the Schema Owner should have some way of saying what happens if one of those clients attempts to mutate a document and doesn't provide a replacement value for an indexed/unstored field -- but there's no easy/fast way for the UpdateHandler to realize that a given document has indexed values for that field -- hence either some simple broad rules the schema owner can put in about hte schema as a whole, or sets of fields the schema owner can define: (if they try to mutate x, y, or z, then they better be providing a, b and c because they are all used together) : default mode. I have not tried to tackle dynamic fields yet... it : seems a bit more complicated! yeah .. that's what i'm worried about with the fieldset idea too. It's one of the reasons why it might be a good idea to just say: * if you want to be able to mutate docs, and you want to be garunteed it will allways work, then every indexed field must be stored. * if you want to be able to mutate docs, and you can't feasible store every indexed field; then add this one line to your schema.xml and Solr will trust that the clients sending mutate requests know what they are doing. * if you don't trust your clients to know what they are doing when mutating documents, add this one line to your schema and Solr will reject any attempt to mutate a document (only wholesale document replacement will be allowed) -Hoss