You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Varun Thacker <va...@gmail.com> on 2014/12/02 03:58:06 UTC
Why do we have a CoreAdminHandler#Load action?
Is there a reason why we have a switch condition to LOAD in code? Can we
remove otherwise.
--
Regards,
Varun Thacker
http://www.vthacker.in/
Re: Why do we have a CoreAdminHandler#Load action?
Posted by Varun Thacker <va...@gmail.com>.
I created SOLR-6814 for this.
On Wed, Dec 3, 2014 at 6:02 AM, Erick Erickson <er...@gmail.com>
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
> <ho...@fucit.org> 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: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Regards,
Varun Thacker
http://www.vthacker.in/
Re: Why do we have a CoreAdminHandler#Load action?
Posted by Erick Erickson <er...@gmail.com>.
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
<ho...@fucit.org> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Why do we have a CoreAdminHandler#Load action?
Posted by Chris Hostetter <ho...@fucit.org>.
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Why do we have a CoreAdminHandler#Load action?
Posted by Varun Thacker <va...@gmail.com>.
Thanks Erick for clarifying that.
So we have two options -
On Tue, Dec 2, 2014 at 8:12 PM, Erick Erickson <er...@gmail.com>
wrote:
> Hmmm, this looks odd, indeed. Perhaps it was an incomplete attempt to
> fix up the fact that after you UNLOAD a core, it's not obvious that
> CREATE (or maybe RELOAD?) would get the core back.
>
> But it doesn't seem to do anything so even if someone uses it, nothing
> happens which is A Bad Thing. Removing it would cause anyone using it
> now to have an error they didn't have before, but I'm hard-pressed to
> believe that that's really worse than failing silently as it does at
> present.
>
1. Deprecate LOAD for Solr 4.10.3 and remove it on trunk and branch_5x
>
> 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.
>
> That said, I'm not able to do the actual work right now so whatever you
> decide.
>
> Erick
>
> On Mon, Dec 1, 2014 at 6:58 PM, Varun Thacker
> <va...@gmail.com> wrote:
> > Is there a reason why we have a switch condition to LOAD in code? Can we
> > remove otherwise.
> >
> > --
> >
> >
> > Regards,
> > Varun Thacker
> > http://www.vthacker.in/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
I think we should deprecate it and remove in 5.x . It's not even documented
here https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API or the
wiki
If anybody doesn't have an strong opinion against it I will create an Jira
for it tomorrow
--
Regards,
Varun Thacker
http://www.vthacker.in/
Re: Why do we have a CoreAdminHandler#Load action?
Posted by Erick Erickson <er...@gmail.com>.
Hmmm, this looks odd, indeed. Perhaps it was an incomplete attempt to
fix up the fact that after you UNLOAD a core, it's not obvious that
CREATE (or maybe RELOAD?) would get the core back.
But it doesn't seem to do anything so even if someone uses it, nothing
happens which is A Bad Thing. Removing it would cause anyone using it
now to have an error they didn't have before, but I'm hard-pressed to
believe that that's really worse than failing silently as it does at
present.
Counter-prorposal: Leave it in and have it call CREATE with minimal
parameters and add LOAD to the docs.
That said, I'm not able to do the actual work right now so whatever you decide.
Erick
On Mon, Dec 1, 2014 at 6:58 PM, Varun Thacker
<va...@gmail.com> wrote:
> Is there a reason why we have a switch condition to LOAD in code? Can we
> remove otherwise.
>
> --
>
>
> Regards,
> Varun Thacker
> http://www.vthacker.in/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org