[
https://issues.apache.org/jira/browse/SOLR-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15390705#comment-15390705
]
Joel Bernstein edited comment on SOLR-9333 at 7/23/16 2:23 PM:
---------------------------------------------------------------
This is a really interesting ticket because it gives Streaming Expressions data
structures. As [~caomanhdat] describes, I think it makes sense to have a *list*
and a *map* as the first two structures. I think both should be implemented as
TupleStreams so that they are interchangeable with other Streams. In this case
it might make sense to use the same syntax as other streams. For example
{code}
map(a="1", b="2", c="3")
list(map(), map(), search())
{code}
The *map* is basically a single Tuple. A *list* contains a list of streams.
Calling read() on a map would return a single Tuple.
Calling read() on a list is a little more complicated. Here is one possible
approach to this:
Calling read() on a list would take the first stream in the list and call
read() on it. Each call to read on the list will continue to read from the
first element in the list. When the first stream in the list returns EOF the
next call to read() on the list will call read() on the second stream() in the
list. The list will keep track of the stream index and add an _index_ property
to each tuple.
The list can also support nested lists:
{code}
list(map(), map(), list(map(), map()))
{code}
The list will keep track of the current depth in the StreamContext and add the
_depth_ parameter to each tuple as well.
So the list would add two properties to each tuple which track the index in the
list and the nesting depth.
was (Author: joel.bernstein):
This is a really interesting ticket because it gives Streaming Expressions data
structures. As [~caomanhdat] describes, I think it makes sense to have a *list*
and a *map* as the first two structures. I think both should be implemented as
TupleStreams so that they are interchangeable with other Streams. In this case
it might make sense to use the same syntax as other streams. For example
{code}
map(a="1", b="2", c="3")
list(map(), map(), search())
{code}
The *map* is basically a single Tuple. A *list* contains a list of streams.
Calling read() on a map would return a single Tuple.
Calling read() on a list is a little more complicated. Here is on possible
approach to this:
Calling read() on a list would take the first stream in the list and call
read() on it. Each call to read on the list will continue to read from the
first element in the list. When the first stream in the list returns EOF the
next call to read() on the list will call read() on the second stream() in the
list. The list will keep track of the stream index and add an _index_ property
to each tuple.
The list can also support nested lists:
{code}
list(map(), map(), list(map(), map()))
{code}
The list will keep track of the current depth in the StreamContext and add the
_depth_ parameter to each tuple as well.
So the list would add two properties to each tuple which track the index in the
list and the nesting depth.
> Add map parameter to streaming expression
> -----------------------------------------
>
> Key: SOLR-9333
> URL: https://issues.apache.org/jira/browse/SOLR-9333
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
>
> Currently in streaming expression, if we wanna provide a list of named/unamed
> parameters. We wrap the values inside a StreamExpressionValue and manually
> separate value based on ',' character.
> In order to make the streaming expression more compact and extendable, I
> propose new kind of parameter to streaming expression.
> {code}
> Map Expression Parameter : { key1 = value1, key2 = value2, .... }
> {code}
> So new tuple stream can be
> {code}
> arrays({term=a, score=1.0}, {term=b, score=2.0})
> or
> search(collection1, q=*:*, fl="id,a_s,a_i,a_f", sort="a_f asc, a_i asc",
> aliases={a_i=alias.a_i, a_s=name})
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
