[
https://issues.apache.org/jira/browse/SOLR-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-10404:
--------------------------------
Attachment: SOLR_10404.patch
Here's a patch that fixes the issue. It also sizes some lists & buffers better,
and it generates a query that won't thrash the queryCache. I also ensured even
the first value has a space before it to avoid a sneaky bug/trick to avoid the
equivalent of a Solr query injection in the value. I've used that to "hack"
known-Solr installations before -- exercise to the reader :-) Granted in this
case it would be exceptionally odd based on how I see the "fetch" feature being
used.
It would be nice to use the "terms" QParser but unfortunately there is no
escaping mechanism for the delimiter :-(
Should the generated query include a collapse on the field? Without it if
multiple records have the value then the user might get multiple records for
some values and no records back for others because "rows" is set. If we don't
want a collapse (usually needless overhead?) then we ought to throw an
exception if the numFound exceeds the rows.
IMO, StreamExpressionTest is too big -- it should be split up. And add useful
test utility methods to avoid mundane repetition... similar to Lucene's
{{BaseTokenStreamTestCase}} utility which is conceptually similar.
> The "fetch" streaming expression should escape join values in generated query
> -----------------------------------------------------------------------------
>
> Key: SOLR-10404
> URL: https://issues.apache.org/jira/browse/SOLR-10404
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.5
> Reporter: David Smiley
> Assignee: David Smiley
> Attachments: SOLR_10404.patch
>
>
> The "fetch" streaming expression joins data from another collection. Example:
> {{expr=fetch(collection,search(...), on="fieldA=fieldB"}}
> Internally, it does this by building a Solr query that looks like
> {{fieldB:(value1 value2 value3)}}. *But those values are not escaped*; they
> should be. See FetchStream.java line 233. The ramification is that, for
> example, if a value contains a colon, then this isn't going to work.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
