>I haven't looked at the patch, but have a couple questions: >* What is the motivation/use case for editing the schema at runtime? (I'm not >suggesting there aren't good ones, just curious)
to add new fields on the fly without having any search downtime >* Would changes be saved? the patch as is just re-reads the schema from the location it's originally set from. all changes are 'saved' > * Why not dynamic fields? becuase the field names start to get too complex. for example you could model the id field in the default schema as a dynamic field: <field name="id" type="string" indexed="true" stored="true" required="true" /> becomes: *_str_it_st_rt_mvf working that out for all possible combinations seems a bit onerous. the default dynamic fields cover most cases but i'm sure my product managers will want one that i don't have the day after we go live. also, if i have extra info about a field like the fact that i don't want it stored i shoudl be able to take advantage of that without having to bounce anything. > it seems to me that restarting a webapp and suffering > downtime is a heavy price to pay just to add a new field or even to just > change an existing field property. >*adding* fields should be relatively straightforward -- the more I learn about >lucene indexing(indexes), it seems like most >schema *changes* require the >index to be rebuilt anyway. correct, i'm fine if we want to restrict the schema 'changes' to only allow the addition of new fields but the index schema also reflects things like default query parsing options and copy fields which shouldn't require and index changes at all which why i went for a more loose approach to start. - will
