: I managed to assign the individual cores to a collection using the collection : API to create the collection and then the solr.xml to define the core(s) and : it's collection. This *seemed* to work. I even test indexed a set of documents : checking totals before and after as well as content. Again, this *seemed* to : work.
You've basically created a collection alias but done it in a way that solr doesn't realize it's a collection alias, and thinks it's a real collection that uses normal routing... : Did I get lucky that all 5k documents were coincidentally found in the : appropriate core(s)? Have I possibly corrupted one or more cores? They are a : working copy so nothing would be lost. you've gotten lucky in the sense that you haven't attempted any update operations yet -- basic queries don't care about the doc routing, so no code paths have been run that will freak out yet. AS soon as you start trying to update the index (adding new docs, replacing docs, etc...) you are going to start getting inconsistencies ... docs with the same unqiueKey on differnet shards, being unable to delete docs by uniqueKey (because the delete request only gets forwarded to one shard, and it's not the one where you have the doc), etc... : Yes this works but isn't this really just a convenient way to avoid the shard : parameter on /select? basically - that's pretty much the whole point of collection aliases. it's a server side control to save the client from needing to specify an list of collections at query time. you can centrally decide what an alias means, and when to redefine it w/o your clients knowing anything changed. -Hoss http://www.lucidworks.com/
