[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14203989#comment-14203989 ] David Smiley commented on SOLR-6191: This feature is going to be awesome; great work guys! I heard about this on the "Solr Cluster" podcast. > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk >Assignee: Noble Paul > Labels: features > Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch, > SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113000#comment-14113000 ] Noble Paul commented on SOLR-6191: -- I completely agree with you that constants help . But, do we need enums for them? I'm happy to use Strings (Others may have their own opinion) . That is a a lot of enums to create. It does not have to be a part of the self describing thing though > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk >Assignee: Noble Paul > Labels: features > Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch, > SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[
https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112984#comment-14112984
]
Vitaliy Zhovtyuk commented on SOLR-6191:
About type safety: maybe wrong term, but in my opinion having
{code}SolrParams.get(MoreLikeThisParameters.MLT){code} is more safe then
{code}SolrParams.get("mlt"){code} used a lot in code, MoreLikeThisParameters
enum relates to documenting parameters and is not so error prone like string
hardcodes, it should be same way for components and handlers to refer
parameters.
> Self Describing SearchComponents, RequestHandlers, params. etc.
> ---
>
> Key: SOLR-6191
> URL: https://issues.apache.org/jira/browse/SOLR-6191
> Project: Solr
> Issue Type: Bug
>Reporter: Vitaliy Zhovtyuk
>Assignee: Noble Paul
> Labels: features
> Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch,
> SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch
>
>
> We should have self describing parameters for search components, etc.
> I think we should support UNIX style short and long names and that you should
> also be able to get a short description of what a parameter does if you ask
> for INFO on it.
> For instance, &fl could also be &fieldList, etc.
> Also, we should put this into the base classes so that new components can add
> to it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102544#comment-14102544 ] Noble Paul commented on SOLR-6191: -- [~vzhovtiuk] The objective of this ticket is not to bring in type safety . The entire Solr commands are implemented without type safety and we should address that separately , if required. The objective here is to self document APIs for the users . Type safety is for developers . It is not easy to achieve it without large-scale rewrite of our components. > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk >Assignee: Noble Paul > Labels: features > Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch, > SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100051#comment-14100051 ] Vitaliy Zhovtyuk commented on SOLR-6191: Annotation approach is beautiful, but it does not describe used in code parameter names since it just string constants. Original goal was to replace all parameter string names with strong typed enum containing parameter string description, see org.apache.solr.common.params.SolrParams. Probably make sense to use both ways and use Parameter enum implementing org.apache.solr.common.params.ParameterDescription as @Param value and don't require component to extend interface. This will bring strong typing code usages and provide generic API for describing parameters. > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk >Assignee: Noble Paul > Labels: features > Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch, > SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[
https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090410#comment-14090410
]
Noble Paul commented on SOLR-6191:
--
I'm confused about the name of the handler {{/meta}}
other options are
* {{/help}}
*{{/man}} linux command
> Self Describing SearchComponents, RequestHandlers, params. etc.
> ---
>
> Key: SOLR-6191
> URL: https://issues.apache.org/jira/browse/SOLR-6191
> Project: Solr
> Issue Type: Bug
>Reporter: Vitaliy Zhovtyuk
>Assignee: Noble Paul
> Labels: features
> Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch
>
>
> We should have self describing parameters for search components, etc.
> I think we should support UNIX style short and long names and that you should
> also be able to get a short description of what a parameter does if you ask
> for INFO on it.
> For instance, &fl could also be &fieldList, etc.
> Also, we should put this into the base classes so that new components can add
> to it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088891#comment-14088891 ] Shalin Shekhar Mangar commented on SOLR-6191: - I think we should split this issue into two APIs: # A node capabilities API which returns all the paths and the request handlers supported by a node # A method introspection API which returns all the parameters required for a method. They might actually be one API endpoint but this will simplify the development because #1 just needs the information in solrconfig.xml and no annotations or interfaces are necessary. #2 can be implemented after the implementation details are fleshed out. Another reason for asking this separation is that I am blocked by the need of #1 for SOLR-6235. > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk >Assignee: Noble Paul > Labels: features > Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[
https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14087670#comment-14087670
]
Noble Paul commented on SOLR-6191:
--
bq.I guess since {{Method.path}} defaults to empty it could be ignored by
components
That is optional . It won't be enforced. Only for requesthandlers with fixed
paths (We plan to fix it for some like, /admin/ping, /replication) we plan to
provide this
bq.but maybe we should have another container annotation like {{Params}}
Yeah, I plan to add something like a {{ParamSet}} or Whatever. This must be
taking care of the multiple pseudo methods handled by a single API example:
CollectionHandler , COreAdminHandler
bq.Handlers can be respond to multiple endpoints, which is configured in
{{solrconfig.xml}}
Yes, You can lookup by path in solrconfig.xml . When the call is received, the
component is looked up and the annotations are fetched at that point
bq.I think whatever solution we land on, it should be possible to fully
describe parameters in a single place
Yes, absolutely
bq.E.g. when initializing and testing handlers/components, will annotations
provide a clean interface to pull named parameters out
That is not taken care of. I agree that it should
> Self Describing SearchComponents, RequestHandlers, params. etc.
> ---
>
> Key: SOLR-6191
> URL: https://issues.apache.org/jira/browse/SOLR-6191
> Project: Solr
> Issue Type: Bug
>Reporter: Vitaliy Zhovtyuk
>Assignee: Noble Paul
> Labels: features
> Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch
>
>
> We should have self describing parameters for search components, etc.
> I think we should support UNIX style short and long names and that you should
> also be able to get a short description of what a parameter does if you ask
> for INFO on it.
> For instance, &fl could also be &fieldList, etc.
> Also, we should put this into the base classes so that new components can add
> to it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[
https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14086726#comment-14086726
]
Steve Rowe commented on SOLR-6191:
--
Nice idea, [~noble.paul], a couple questions:
# You imply by naming the outer annotation {{Method}} that it will always be
applied to classes that serve as REST(-like) endpoints, but that won't be true
for components; I guess since {{Method.path}} defaults to empty it could be
ignored by components, but maybe we should have another container annotation
like {{Params}} to hold multiple {{Param}} annotations when the class doesn't
need a {{path}}?
# Handlers can be respond to multiple endpoints, which is configured in
{{solrconfig.xml}}, rather than at compile-time; how do you think this should
be handled?
# I think whatever solution we land on, it should be possible to fully describe
parameters in a single place. Will annotations suffice to handle all
param-related functionality? E.g. when initializing and testing
handlers/components, will annotations provide a clean interface to pull named
parameters out? (Your patch doesn't illustrate this at all.)
> Self Describing SearchComponents, RequestHandlers, params. etc.
> ---
>
> Key: SOLR-6191
> URL: https://issues.apache.org/jira/browse/SOLR-6191
> Project: Solr
> Issue Type: Bug
>Reporter: Vitaliy Zhovtyuk
>Assignee: Noble Paul
> Labels: features
> Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch
>
>
> We should have self describing parameters for search components, etc.
> I think we should support UNIX style short and long names and that you should
> also be able to get a short description of what a parameter does if you ask
> for INFO on it.
> For instance, &fl could also be &fieldList, etc.
> Also, we should put this into the base classes so that new components can add
> to it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083889#comment-14083889 ] Noble Paul commented on SOLR-6191: -- I guess it is better to use java annotations to describe the params than using interfaces. The problem with interfaces is that you need to instantiate a class to get the details. I shall take another stab at this and post a patch > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk > Labels: features > Attachments: SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045680#comment-14045680 ] Shalin Shekhar Mangar commented on SOLR-6191: - This looks great, thank you Vitaliy! > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk > Labels: features > Attachments: SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
