Right, #2 here is just sugar over abusing the CREATE command for nice symmetry.
I don't have much in the way of strong feelings here.... Erick On Tue, Dec 2, 2014 at 3:10 PM, Chris Hostetter <[email protected]> wrote: > > FWIW, "LOAD" has (as far as i understand) been basically deprecated since > day #1. > > as described on the old wiki... > >>> /!\ not implemented yet! Use CREATE >>> >>> So far, no use cases have been presented for a LOAD command that aren't >>> satisfied by using CREATE so it's doubtful that a separate LOAD command >>> will be implemented unless such a use-case is found. > > ... i suspect the original expectation was that LOAD/UNLOAD would be a > matching pair, while CREATE/DESTROY would be matching pair -- except a > "DESTROY" was never added, instead new "deleteXxxx=true" options were > added to unload. > > It also makes more sense pre "core discovery" when CREATE required a name > & an instancedir and recorded them in solr.xml, and UNLOAD (w/o the delete > options) just noted in solr.xml that for that core "loadOnStartup=false" > ... in which case it would make sense that you might want to later LOAD a > core by name w/o needing ot specify an instance dir. > > : 1. Deprecate LOAD for Solr 4.10.3 and remove it on trunk and branch_5x > > Not an option - we can't be deprecating stuff in a bug fix release. > > Deprecate in 5.0 and remove in 6.0 is totally viable however. > > > in the mean time, we can still do #2... > > : > Counter-prorposal: Leave it in and have it call CREATE with minimal > : > parameters and add LOAD to the docs. > ... > : 2. Essentially not pass down the core.properties keys etc. > > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
