[
https://issues.apache.org/jira/browse/SOLR-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072812#comment-15072812
]
Dennis Gove edited comment on SOLR-8458 at 12/28/15 3:27 PM:
-------------------------------------------------------------
As I see it there are 2 pieces here, both related but separate.
First, adding support for parameter substitution in an expression. This would
be handled with the changes I discussed above to StreamFactory, StreamParser,
and the addition of a new type StreamExpressionSubstitutionParameter. Note that
this doesn't necessarily care how the expressions come in.
And second, adding support for parameter substitution in StreamHandler and in
an http request. I like the syntax Joel uses in the description. What this
would mean is that StreamHandler would see http params like "expr", "left" and
"right", would know that these are expressions (can call into StreamFactory to
check if something is a valid expression), and would pass them off
independently to be parsed and then together to be pieced together.
This approach modularizes the implementation such that how an expression with
substitution comes in via http is independent to how it is handled within the
Streaming API.
For example, the following comes into StreamHandler
{code}
http://localhost:8983/col/stream?expr=merge($left, $right,
...)&baz=jaz&left=search(...)&right=search(...)&foo=bar
{code}
The StreamHandler will see five parameters, expr, baz, left, right, and foo. It
would then determine that expr, left, and right are valid expressions and pass
them off to be parsed into three expression objects. It would then pass all
three into the factory to be combined into a single Stream object. The factory
would then iterate (recursively?) until there aren't any more instances of a
StreamExpressionSubstitutionParameter at any level (considering the possibility
of infinite loops, of course). At this point it'd then just be passed off to
create a Stream object as any other expression would be.
Another possibility would be to parse out the substitution expressions and then
register them in the factory for use during Stream object creation. This would
negate the need to do that pre-processing of the N substitution expression and
would give a place to register "pre-compiled" expressions. I'm not a huge fan
of this approach as it would add more state to the factory and I'm not a huge
fan of the state it already contains.
I'm happy to take this on unless, [~caomanhdat], you want to continue your work
on it.
was (Author: dpgove):
As I see it there are 2 pieces here, both related but separate.
First, adding support for parameter substitution in an expression. This would
be handled with the changes I discussed above to StreamFactory, StreamParser,
and the addition of a new type StreamExpressionSubstitutionParameter. Note that
this doesn't necessarily care how the expressions come in.
And second, adding support for parameter substitution in StreamHandler and in
an http request. I like the syntax Joel uses in the description. What this
would mean is that StreamHandler would see http params like "expr", "left" and
"right", would know that these are expressions (can call into StreamFactory to
check if something is a valid expression), and would pass them off
independently to be parsed and then together to be pieced together.
This approach modularizes the implementation such that how an expression with
substitution comes in via http is independent to how it is handled within the
Streaming API.
For example, the following comes into StreamHandler
{code}
http://localhost:8983/col/stream?expr=merge($left, $right,
...)&baz=jaz&left=search(...)&right=search(...)&foo=bar
{code}
The StreamHandler will see five parameters, expr, baz, left, right, and foo. It
would then determine that expr, left, and right are valid expressions and pass
them off to be parsed into three expression objects. It would then pass all
three into the factory to be combined into a single Stream object. The factory
would then iterate (recursively?) until there aren't any more instances of a
StreamExpressionSubstitutionParameter at any level (considering the possibility
of infinite loops, of course). At this point it'd then just be passed off to
create a Stream object as any other expression would be.
Another possibility would be to parse out the substitution expressions and then
register them in the factory for use during Stream object creation. This would
negate the need to do that pre-processing of the N substitution expression and
would give a place to register "pre-compiled" expressions. I'm not a huge fan
of this approach as it would add more state to the factory and I'm not a huge
fan of the state it already contains.
> Parameter substitution for Streaming Expressions
> ------------------------------------------------
>
> Key: SOLR-8458
> URL: https://issues.apache.org/jira/browse/SOLR-8458
> Project: Solr
> Issue Type: Improvement
> Reporter: Joel Bernstein
> Priority: Minor
> Attachments: SOLR-8458.patch
>
>
> As Streaming Expressions become more complicated it would be nice to support
> parameter substitution. For example:
> {code}
> http://localhost:8983/col/stream?expr=merge($left, $right,
> ...)&left=search(...)&right=search(...)
> {code}
--
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
