linslee75 commented on PR #5194: URL: https://github.com/apache/solr/pull/5194#issuecomment-6458936617
> The question/concern is... is it a reasonable expectations to be able to query on a field after a schema API change without explicitly doing something in-between. I've not used the schema API so I don't know. I'm sympathetic to backwards-compatibility, and I'm sympathetic to a user having to do _something_ (an explicit commit or reload). If there was some implicit commit/reload... that would not have been my choice had I designed the API in the first place. But I didn't. Another option is declaring a change and gate it on a flag that disappears come 11. Thanks for weighing in, David. I’ve been thinking a bit more about the tradeoffs and wanted to share this as input for the discussion. One concern with reopening searchers or issuing soft commits after schema updates is the cost under repeated additions. Schemaless can add fields as documents arrive, and Schema API clients can submit additions in quick succession. Today, each successful Schema API request triggers a core reload, so multiple requests can already cause repeated reloads. Replacing those reloads with searcher reopens or soft commits would avoid the core reload, but could still trigger repeated searcher opens, potentially on every replica. Coalescing updates could reduce that work, but would introduce a separate scheduling and visibility policy. My preference is not to reopen searchers or issue commits as a side effect of schema additions. I’d keep Schema API behavior aligned with Schemaless: publish the new schema, and let the next normal commit or soft commit open a searcher that uses it. Until then, queries that validate fields against the current searcher’s schema may reject the new field. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
