: However, the wiki recommends against using the ALIAS command in CoreAdmin in : a couple of places, and SOLR-1637 says it's been removed now anyway.
correct, there were a lot of problems with how to cleanly/sanely deal with core operations on aliases -- he command may return at some future date if there is a better seperation between the concept of an "authoritative' name for a core, and aliases -- but in the meantime, i wouldn't recomend using it even in older versions of Solr where it (sort of) worked. : If I can't use ALIAS safely, is it okay to just symlink the most recent : core's instance (or data) directory to 'current', and bring it up in Solr as : a separate core? Will this be safe, as long as all index writing happens via : the 'current' core? i would not recommend that -- as long as you only index to one of those cores, and use "commits" to force the other instances to reload from disk there wouldn't be any errors -- but you'll wind up duplicating all of the internal memory strucutures (index objects, and caches) a cleaner way to deal with this would be do use something like RewriteRule -- either in your appserver (if it supports a feature like that) or in a proxy sitting in front of Solr. Frankly though: indexing code can usually be made fairly smart -- pretty much every programming langauge i nthe world makes it fairly easy to generate a string using the pattern "http://server:8983/solr/${YY-MM-DD}/update";, and then you just POST to that. -Hoss
