Chris Hostetter wrote:
I'm going to sidestep the issue of wether there *was* a good reason for it, as well as the "does the singleton pattern make sense for the current usage" question and answer what i think is an equally significant question: "what are the implications of trying to change it now?" ... the biggest i can think of being that SolrConfig is also a static singleton, and a *lot* of code in the Solr code base would need to be changed to support multiple SolrConfigs ... and without multiple SolrConfigs, there really isnt' any reason to have multiple SolrCores.
This actually underlines that my guess was right to a certain extent. Changing from singleton is not straightforward.
I am currently in the startup phase of my thesis regarding open source and enterprise search. After having worked at perhaps the leading major enterprise search company, I have the impression that multiple collections is a very common feature (and very sought-after). It is a trend I see not just directly from my work, but most certainly also as a result of enterprise search solutions becoming more common in general.
However I must say that Solr seems to be approaching the problem from a very logical angle. What really is missing is a more abstract layer, call it application framework, that probably will come afterwards anyway. This will perhaps evolve naturally as part of the Solr project at a later stage, or perhaps even as a separate open source project building on Solr.
Until this framework is available with its appropriate configuration files, administrator interface and so on in place, it seems a bit unnatural to support multiple collections from the same application instance.
Bottom line (for now): I think that users looking for enterprise search solutions must have a simple way of creating multiple collections from within the same application.
I apologize for my very philosophical e-mail, but I tend to become somewhat visionary and conceptual after a few beers, and this might not be the perfect forum for these discussions(?) :)
Eivind