I'm glad to hear at least *somebody* other than me likes the idea :-) I started some manual experimentation with it. After I got past one little bug, sure enough it worked and would show up in the admin screen. It showed up because of the /admin/luke handler interacting with IndexSchema, *not* as I said due to using the HTTP schema API since it doesn't use that. Either way, that works. And after some schema manipulation (performed easily via Solr's admin screen which has a form to add field types), I saw the schema get persisted which, as I expected, displayed the field type definition there.
But then I got to wonder if that's actually a good thing, and I'm now thinking probably not. (We could have implicit types with or without this behavior.) Why not? (A) This field type was serialized incorrectly; there were no analyzers when there should have been some. This has little to do with implicit field types; it's due to assumptions in our schema / field type serialization that simply give up unless it sees a TokenizerChain subclass of Analyzer, whereas in my code I chose to use a CustomAnalzyer Lucene utility in-code. I could "fix" this by using TokenizerChain instead or change the serialization code, but still, it ought to be tested since it's a sneaky bug (won't throw an error). Or alternatively never persist implicit field types; though _that_ would need to be tested. (B) It can sometimes thwart future changes we may choose for a type's definition. Since it shows up, it's somewhat locked in at the time the schema is manipulated with the schema API (with whatever the impl is considering Solr/luceneMatchVersion was at that time). After that point, if the user were to keep the config, then delete all data, then update luceneMatchVersion in solrconfig, then index again, it would still have the same field type definition as it did prior because the field type is explicitly defined at this point. This isn't a huge deal since apps deploy/publish their configuration in different ways, and most popular ways would be immune to this (to be affected, the app must manipulate the schema with the API). Even apps that do manipulate the schema with the API might do major revision upgrades in a from-scratch way instead of using the same config in-place. And it's a hypothetical scenario of a future point in time where we eventually change our mind on what some particular implicit field type ought to do. To have implicit field types not persisted, the simplest impl would probably simply never save back such implicit field types into the IndexSchema's registry of field types, and thus it won't be iterated to be persisted. 'course it'd need a test. ~ David -- Lucene/Solr Search Committer (PMC), Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
