I created SOLR-6814 for this. On Wed, Dec 3, 2014 at 6:02 AM, Erick Erickson <[email protected]> wrote:
> 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] > > -- Regards, Varun Thacker http://www.vthacker.in/
