I'm trying to choose between embedding Lucene versus embedding Solr in one webapp.
In Solr terms, functional requirements would more or less lead to multiple schema & conf (need CRUD/generation on those) and deployment constraints imply one webapp instance. The choice I'm trying to make is thus: -Embed Lucene and (attempt to) recode a lot of what Solr provides... (the straw man) -Embed Solr but refactor 'some' of its core, assuming it is correct to see one Solr core as the association of one schema & one conf. There have been a few threads about multiple indexes and/or multiple/reloading schemas. >From what I gathered, one solution stems from the 'multiple webapp instances deployment' and implies 'extracting' the static instance (at least the SolrCore) & thus host multiple Solr cores in one webapp. Obviously, the operations (queries/add/delete doc) would need to carry which core they are targeting (one 'core' being set as the 'default' for compatibility purpose). What will be the other big hurdles, the ones that could even preclude the very idea ? (caches handling, updater threads, HA features...) Are there any easier routes (class-loaders, 'provisional' schema...) ? Any advice welcome. Thanks. Henri -- View this message in context: http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a9981355 Sent from the Solr - User mailing list archive at Nabble.com.
