IMO forcing the users to do configuration change in Solr or in their
application is the same thing - it all boils down to configuration
change (I'll be very surprised if someone is actually hardcoding the
Solr URL in their system - most probably it is configurable, and if it's
not, forcing them to change it is actually a good thing).
Besides,
if there's only one core, why need a name?
Consistency. Having a default core as Israel suggested can probably do
the trick. But, at first it might seem that having a default core and
not needing to specify the core name will make it easier for users to
use. But I actually disagree - don't under estimate the power of being
consistent. I rather have a manual telling me "this is how it works and
it always work like that in all scenarios" then having something like
"this is how it works but if you have scenario A then it works
differently and you have to do this instead".
Shalin Shekhar Mangar wrote:
On Mon, Sep 14, 2009 at 8:16 PM, Uri Boness <ubon...@gmail.com> wrote:
Is it really a problem? I mean, as i see it, solr to cores is what RDBMS is
to databases. When you connect to a database you also need to specify the
database name.
The problem is compatibility. If we make solr.xml compulsory then we only
force people to do a configuration change. But if we make a core name
mandatory, then we force them to change their applications (or the
applications' configurations). It is better if we can avoid that. Besides,
if there's only one core, why need a name?
