Forgive me if i'm off base with some stuff here ... i'm still trying to
wrap my head arround some of the new multicore stuff.
Ryan's comments in SOLR-428 have made me realize that the "default" core
means more then i thought. I had missunderstood it to be a way of
specifying what the "legacy" singlton core should be ... but based on on
SOLR-428 I'm now getting the sense that the default core identifies what
core to use if no core is specified in the URL, soif this is your
multicore.xml...
<multicore adminPath="/admin/multicore" persistent="true">
<core name="core0" instanceDir="core0" default="true"/>
<core name="core1" instanceDir="core1" />
</multicore>
...then these two URLs are equivilent, correct?
http://localhost:8983/solr/@core0/select?q=*:*
http://localhost:8983/solr/select?q=*:*
If i may ask: what is the motivation for this? isn't it fair to assume
that if people want to use multiple cores they can include the core name
in every URL?
The one use case i can think of is that based on the "SETASDEFAULT" option
of the MultiCoreHandler i suspect people want to do stuff like this...
1. start up server with a single "core0" as default
2. use default URLs all day long...
GET http://localhost:8983/solr/select?q=bar
POST http://localhost:8983/solr/update ...
GET http://localhost:8983/solr/select?q=foo
3. decide you want to change the schema or something,
load a new "core0"
4. rebuild your index using "core0" urls...
POST http://localhost:8983/solr/@core1/update ...
5. once you're happy with "core1", set it as the default,
and unload core0...
GET
http://localhost:8983/solr/admin/multicore?action=SETASDEFAULT&core=core1
GET http://localhost:8983/solr/admin/multicore?action=UNLOAD&core=core0
6. keep using core1 just like you use to use core0 with
default urls...
GET http://localhost:8983/solr/select?q=bar
POST http://localhost:8983/solr/update ...
GET http://localhost:8983/solr/select?q=foo
...this seems like a really cool use case of multicores, but it also seems
like it is incompartible with the primary goal of multicores: having lots
of different indexes; afterall: there's only one default, so you can only
use this trick with one of your indexes.
It seems like if this is the only "perk" or having a "default" core, it
would make more sense to require a core name in every url (when multicore
support is turned on) and replace the SETASDEFAULT operation with a
RENAME operation that changes the name of a core (unloading any previous
core that was using that name) ... or maybe even support multiple names
per core, with some ADDNAME, REMOVENAME, and MOVENAME options...
1 /admin/multicore?action=ADDNAME&coreDir=cores/dir0&name=yak
2 /@yak/select?q=*:*
3 /admin/multicore?action=ADDNAME&coreDir=cores/dir1&name=foo
4 /@foo/select?q=*:*
5 /admin/multicore?action=ADDNAME&coreDir=cores/dir1&name=bar
6 /@bar/select?q=*:*
(#4 and #6 are now equivilent)
7 /admin/multicore?action=REMOVENAME&coreDir=cores/dir1&name=foo
(now #4 no longer works)
8 /admin/multicore?action=MOVENAME&coreDir=cores/dir0&name=bar
(now #2 and #6 are equivilent)
thoughts?
-Hoss
