[jira] [Assigned] (SOLR-10288) Javascript housekeeping in UI
[ https://issues.apache.org/jira/browse/SOLR-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned SOLR-10288: --- Assignee: Erik Hatcher > Javascript housekeeping in UI > - > > Key: SOLR-10288 > URL: https://issues.apache.org/jira/browse/SOLR-10288 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 6.4.2 >Reporter: Shawn Heisey >Assignee: Erik Hatcher >Priority: Minor > Time Spent: 1h 40m > Remaining Estimate: 0h > > I noticed a couple of things about the javascript files included in Solr for > the Admin UI: > * There is unnecessary duplication between the "js" and "libs" directories. > * Some of the files are not minified, and for some of those that are, the > non-minified originals are still included in the binary release. > Removing the duplicates entirely and the non-minified files from the binary > release would shave a little bit of size off of the binary download. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10288) Javascript housekeeping in UI
[ https://issues.apache.org/jira/browse/SOLR-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved SOLR-10288. - Resolution: Fixed dusting off commit privs... may have done the push with more intermediate commits than I should have, so I'm learning. --squash? > Javascript housekeeping in UI > - > > Key: SOLR-10288 > URL: https://issues.apache.org/jira/browse/SOLR-10288 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 6.4.2 >Reporter: Shawn Heisey >Assignee: Erik Hatcher >Priority: Minor > Time Spent: 1h 40m > Remaining Estimate: 0h > > I noticed a couple of things about the javascript files included in Solr for > the Admin UI: > * There is unnecessary duplication between the "js" and "libs" directories. > * Some of the files are not minified, and for some of those that are, the > non-minified originals are still included in the binary release. > Removing the duplicates entirely and the non-minified files from the binary > release would shave a little bit of size off of the binary download. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865549#comment-16865549 ] Erik Hatcher commented on SOLR-13537: - Fully seconded everything you said, [~gerlowskija] Visibility to a matrix of various builds is a holy grail here, and taking the steps to get a first pass of compilation-only badges gets a useful addition to readily spot the (unusual) compilation, or precommit, failure. > Build Status Badge in git README > > > Key: SOLR-13537 > URL: https://issues.apache.org/jira/browse/SOLR-13537 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (9.0), 8.2 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: Markdown Preview Of Build Status README.png, Simple > Artifact Build Badge.png, Simple Artifact Build Badges.png > > Time Spent: 10m > Remaining Estimate: 0h > > In order to aid developers and DevOps engineers who are working in a > git-driven ecosystem, it would be helpful to see the status builds in the > README. This is a standard for many open source projects. I think one could > debate whether we should have a multi-line build badge visual in the README > because people need to know about the builds for various versions and > platforms in the case of Lucene/Solr because it is such a large and widely > used project, in a variety of environments. The badges not only celebrate > that fact, they support its persistence in the future with new developers who > look for such information instictively. > I would recommend the active build pipelines (currently 8.x and 9.x) for each > platform, Linux, Windows, MacOSX, and Solaris. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13422) bin/post command not working when run from crontab
[ https://issues.apache.org/jira/browse/SOLR-13422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824121#comment-16824121 ] Erik Hatcher commented on SOLR-13422: - Carsten - thanks for filing this. I'll take ownership of it, with the caveat that I don't know when I'll get to tackling this myself; given the reasonable workaround, I'll keep this on the back burner. I've only ever run `bin/post` interactively myself, so I haven't yet experienced this myself - sorry for letting this one go unnoticed til now. > bin/post command not working when run from crontab > -- > > Key: SOLR-13422 > URL: https://issues.apache.org/jira/browse/SOLR-13422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: 7.5, 7.7.1 >Reporter: Carsten Agger >Assignee: Erik Hatcher >Priority: Major > Labels: features > > I'm working with a script where I want to send a command to delete all > elements in an index; notably, > > /opt/solr/bin/post -c -d > "*:*" > > When run interactively, this works fine. > However, when run automatically as a cron job, it gives this interesting > output: > Unrecognized argument: "*:*" > If this was intended to be a data file, it does not exist relative to /root > The culprit seems to be these lines, 143-148: > if [[ ! -t 0 ]]; then > MODE="stdin" > else > #when no stdin exists and -d specified, the rest of the arguments > #are assumed to be strings to post as-is > MODE="args" > > This code seems to be doing the opposite of what the comment says - it sets > MODE="stdin" if stdin is NOT a terminal, but if it IS (i.e., there IS an > stdin) it assumes the rest of the args can be posted as-is. > On the other hand, if the condition is reversed, my command will fail > interactively but not when run as a cron job. Both options are, of course, > unsatisfactory. > It _will_ actually work in both cases, if instead the command to delete the > contents of the index is written as: > echo "*:*" | /opt/solr/bin/post -c > departments -d > I've confirmed this bug in SOLR v. 7.7.1 and 7.5 - it is presumably present > in more versions. > I've raised the issue on the solr-user mailing list, where I was asked to > file a Jira report. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13422) bin/post command not working when run from crontab
[ https://issues.apache.org/jira/browse/SOLR-13422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned SOLR-13422: --- Assignee: Erik Hatcher > bin/post command not working when run from crontab > -- > > Key: SOLR-13422 > URL: https://issues.apache.org/jira/browse/SOLR-13422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: 7.5, 7.7.1 >Reporter: Carsten Agger >Assignee: Erik Hatcher >Priority: Major > Labels: features > > I'm working with a script where I want to send a command to delete all > elements in an index; notably, > > /opt/solr/bin/post -c -d > "*:*" > > When run interactively, this works fine. > However, when run automatically as a cron job, it gives this interesting > output: > Unrecognized argument: "*:*" > If this was intended to be a data file, it does not exist relative to /root > The culprit seems to be these lines, 143-148: > if [[ ! -t 0 ]]; then > MODE="stdin" > else > #when no stdin exists and -d specified, the rest of the arguments > #are assumed to be strings to post as-is > MODE="args" > > This code seems to be doing the opposite of what the comment says - it sets > MODE="stdin" if stdin is NOT a terminal, but if it IS (i.e., there IS an > stdin) it assumes the rest of the args can be posted as-is. > On the other hand, if the condition is reversed, my command will fail > interactively but not when run as a cron job. Both options are, of course, > unsatisfactory. > It _will_ actually work in both cases, if instead the command to delete the > contents of the index is written as: > echo "*:*" | /opt/solr/bin/post -c > departments -d > I've confirmed this bug in SOLR v. 7.7.1 and 7.5 - it is presumably present > in more versions. > I've raised the issue on the solr-user mailing list, where I was asked to > file a Jira report. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7188) Run Data Import Handler processes in a SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823634#comment-16823634 ] Erik Hatcher commented on SOLR-7188: A _noble_ effort here, but is it something anyone will pick up an continue? [~noble.paul]? > Run Data Import Handler processes in a SolrJ client > --- > > Key: SOLR-7188 > URL: https://issues.apache.org/jira/browse/SOLR-7188 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ted Sullivan >Priority: Minor > Attachments: ESS_as_a_copy.patch, IDEA-AS-CODE.patch, > SOLR-7188.patch, SOLR-7188.patch, SOLR-7188.patch, SOLR-7188.patch, > SOLR-7188.patch > > > Adds a DataImportHandlerClient class that wraps an EmbeddedSolrServer and > adds a DIHCloudWriter implementation of DIHWriter that sends documents to a > remote SolrCloud cluster. This enables existing DIH processes to run outside > of the Solr JVM which should enable better scalability. > The current architecture of DIH imposes several restrictions on scalability. > First, the DIH runs in the same process space as Solr itself and competes for > resources (CPU and memory) with normal Solr processes devoted to indexing and > querying. Second, the DIH cannot be multi-threaded which means that > parallelizing it requires splitting the processing amongst nodes in a > SolrCloud cluster. Since the incoming data is sent through an > UpdateRequestProcessor chain (via the SolrWriter implementation of > DIHWriter), additional routing is done internally as the documents are > forwarded to the current shard leader nodes once the ID hash is computed. > This causes additional network traffic within the SolrCloud cluster. Scaling > the DIH is limited by the number of nodes in the cluster and any heavy-duty > processing due to entity processors or transformation elements shares the > processing resources of Solr itself. This is known to be a source of > bottlenecks in Solr installations (SolrCloud or Master-Slave) that use DIH. > The DataImportHandlerClient uses native DIH functionality - DataImporter, > etc. but can be run externally to Solr. This means that as many processes as > are needed to achieve necessary performance at scale can be added and the > processing that occurs within the DataImportHandler is done outside of the > Solr JVM. The same benefits that accrue with multiple SolrJ clients can now > be realized with DIH without the necessity of porting code from DIH to a > SolrJ client. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7136) Add an AutoPhrasing TokenFilter
[ https://issues.apache.org/jira/browse/SOLR-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823632#comment-16823632 ] Erik Hatcher commented on SOLR-7136: I believe we can close this one, as the rationale for this was because we could not turn off splitting on whitespace. All better now? Thank you [[~tedsullivan]] for your patience! *bows* > Add an AutoPhrasing TokenFilter > --- > > Key: SOLR-7136 > URL: https://issues.apache.org/jira/browse/SOLR-7136 > Project: Solr > Issue Type: New Feature >Reporter: Ted Sullivan >Priority: Major > Attachments: AutoPhaseFiniteStateDiagram.pdf, SOLR-7136.patch, > SOLR-7136.patch, SOLR-7136.patch, SOLR-7136.patch > > > Adds an 'autophrasing' token filter which is designed to enable noun phrases > that represent a single entity to be tokenized in a singular fashion. Adds > support for ManagedResources and Query parser auto-phrasing support given > LUCENE-2605. > The rationale for this Token Filter and its use in solving the long standing > multi-term synonym problem in Lucene Solr has been documented online. > http://lucidworks.com/blog/automatic-phrase-tokenization-improving-lucene-search-precision-by-more-precise-linguistic-analysis/ > https://lucidworks.com/blog/solution-for-multi-term-synonyms-in-lucenesolr-using-the-auto-phrasing-tokenfilter/ -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13336) maxBooleanClauses ignored; can result in exponential expansion of naive queries
[
https://issues.apache.org/jira/browse/SOLR-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815911#comment-16815911
]
Erik Hatcher commented on SOLR-13336:
-
+1 to this. Hoss' analysis is thorough, and the patch hits the spot.
> maxBooleanClauses ignored; can result in exponential expansion of naive
> queries
> ---
>
> Key: SOLR-13336
> URL: https://issues.apache.org/jira/browse/SOLR-13336
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.0, 7.6, master (9.0)
>Reporter: Michael Gibney
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13336.patch, SOLR-13336.patch
>
>
> Since SOLR-10921 it appears that Solr always sets
> {{BooleanQuery.maxClauseCount}} (at the Lucene level) to
> {{Integer.MAX_VALUE-1}}. I assume this is because Solr parses
> {{maxBooleanClauses}} out of the config and applies it externally.
> In any case, when used as part of
> {{lucene.util.QueryBuilder.analyzeGraphPhrase}} (and possibly other places?),
> the Lucene code checks internally against only the static {{maxClauseCount}}
> variable (permanently set to {{Integer.MAX_VALUE-1}} in the context of Solr).
> Thus in at least one case ({{analyzeGraphPhrase()}}, but possibly others?),
> {{maxBooleanClauses}} is having no effect. I'm pretty sure this is what's
> underlying the [issue reported here as being related to Solr
> 7.6|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201902.mbox/%3CCAF%3DheHE6-MOtn2XRbEg7%3D1tpNEGtE8GaChnOhFLPeJzpF18SGA%40mail.gmail.com%3E].
> To summarize, users are definitely susceptible (to varying degrees of likely
> severity, assuming no actual _malicious_ attack) if:
> # Running Solr >= 7.6.0
> # Using edismax with "ps" param set to >0
> # Query-time analysis chain is _at all_ capable of producing graphs (e.g.,
> WordDelimiterGraphFilter, SynonymGraphFilter that has corresponding synonyms
> with varying token lengths.
> Users are _particularly_ vulnerable in practice if they have query-time
> {{WordDelimiterGraphFilter}} configured with {{preserveOriginal=true}}.
> To clarify, Lucene/Solr 7.6 didn't exactly _introduce_ the issue; it only
> increased the likelihood of problems manifesting (as a result of
> LUCENE-8531). Notably, the "enumerated strings" approach to graph phrase
> query (reintroduced by LUCENE-8531) was previously in place pre-6.5 – at
> which point it could rely on default Lucene-level {{maxClauseCount}} failsafe
> (removed as of 7.0). This explains the odd "Affects versions" =>
> maxBooleanClauses was disabled at the Lucene level (in Solr contexts)
> starting with version 7.0, but the change became more likely to manifest
> problems for users as of 7.6.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13390) Provide Query Elevation Component by default
Erik Hatcher created SOLR-13390: --- Summary: Provide Query Elevation Component by default Key: SOLR-13390 URL: https://issues.apache.org/jira/browse/SOLR-13390 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Erik Hatcher Like other components, like highlighting and faceting, it'd be useful to have this work out of the box by just enabling it on the request. Currently the component needs to be added to `/select` and an empty elevate.xml file needs to be added to the config - a bit unnecessarily arduous. Let's add the component to `/select` and modify the component to be happy with or without an elevate.xml (since id's can be sent on the request to elevate, so fixed config isn't needed either). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13335) Upgrade to velocity 2.0 and velocity-tools 3.0
[ https://issues.apache.org/jira/browse/SOLR-13335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797974#comment-16797974 ] Erik Hatcher commented on SOLR-13335: - +1 to upgrading Velocity and removing commons-lang. > Upgrade to velocity 2.0 and velocity-tools 3.0 > -- > > Key: SOLR-13335 > URL: https://issues.apache.org/jira/browse/SOLR-13335 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13335.patch, SOLR-13335.patch > > Time Spent: 10m > Remaining Estimate: 0h > > As part of looking to remove old commons-lang in SOLR-9079, found that > velocity depends on it. Upgrading Velocity would allow completely removing > commons-lang > Copy some detail from SOLR-9079 investigation: > * solr/contrib/velocity/ivy.xml doesn't even reference commons-lang > * velocity 1.7 was released - 2010-11-29 > * LUCENE-5249 from 2013 was the last time velocity was changed in > lucene/ivy-versions.properties > * velocity-tools 2.0 has an optional dependency on commons-lang > * velocity 1.7 has a hard dependency on commons-lang. > Upgrading velocity 1.7 -> 2.0 > * http://velocity.apache.org/engine/2.0/upgrading.html > * Change velocity to velocity-engine-core > * upgrades commons-lang to commons-lang3 > So if we want to finish removing commons-lang, we need to upgrade velocity. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7515) Some highlight checkboxes are broken
[ https://issues.apache.org/jira/browse/SOLR-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761230#comment-16761230 ] Erik Hatcher commented on SOLR-7515: The `hl.requireFieldMatch` checkbox must have been added since this issue was created, mentioned in the duplicate SOLR-13221 - noting here as the patch here doesn't include that. > Some highlight checkboxes are broken > > > Key: SOLR-7515 > URL: https://issues.apache.org/jira/browse/SOLR-7515 > Project: Solr > Issue Type: Bug > Components: Admin UI >Reporter: Matt Hilt >Priority: Minor > Attachments: SOLR-7515.patch > > > In the query UI, when configuring a highlight enabled search, there are three > checkboxes for additional highlight parameters. When they are checked, they > add the appropriate parameters to the query, e.g. > hl.usePhraseHighligher=true > However, usePhraseHighligher and highlightMultiTerm are true by default > (according to the 5.1 docs). So these checkboxes really don't do anything, > and there is no way to turn off these parameters from the GUI. > The solution is to make the parameters always part of the query (when > highlighting is on), and just toggle the true/false value. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13221) Solr Admin Query UI: highlighting parameter checkboxes not functioning
Erik Hatcher created SOLR-13221: --- Summary: Solr Admin Query UI: highlighting parameter checkboxes not functioning Key: SOLR-13221 URL: https://issues.apache.org/jira/browse/SOLR-13221 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI Reporter: Erik Hatcher When using the Solr Admin UI Query "tab", several of the highlighting checkboxes are not functioning. When hl is checked the checkboxes hl.requireFieldMatch, hl.usePhraseHighlighter, and hl.highlightMultiTerm do not set the appropriate request parameters. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10705) Upgrade Velocity's version of jquery from 1.7.2 to 2.1.3
[ https://issues.apache.org/jira/browse/SOLR-10705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574018#comment-16574018 ] Erik Hatcher commented on SOLR-10705: - throw away Velocity? It's a perfectly useful response writer unto itself. But I realize that "velocity" gets conflated with jquery and folks think of it only as /browse. So maybe what is meant is that the /browse as a UI is probably what you desire to replace with something more modern. > Upgrade Velocity's version of jquery from 1.7.2 to 2.1.3 > > > Key: SOLR-10705 > URL: https://issues.apache.org/jira/browse/SOLR-10705 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Velocity >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > ...in order to avoid shipping both versions. This requires selecting another > autocomplete plugin, since the one in use > https://github.com/agarzola/jQueryAutocompletePlugin is abandoned -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10705) Upgrade Velocity's version of jquery from 1.7.2 to 2.1.3
[ https://issues.apache.org/jira/browse/SOLR-10705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573420#comment-16573420 ] Erik Hatcher commented on SOLR-10705: - Velocity and jquery are tangential, unrelated technologies. (jquery for ajax requests, velocity for server-side templating/response writing) +1 to jquery upgrade (and velocity for that matter, though that might have some API changes that need to be made?) > Upgrade Velocity's version of jquery from 1.7.2 to 2.1.3 > > > Key: SOLR-10705 > URL: https://issues.apache.org/jira/browse/SOLR-10705 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Velocity >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > ...in order to avoid shipping both versions. This requires selecting another > autocomplete plugin, since the one in use > https://github.com/agarzola/jQueryAutocompletePlugin is abandoned -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5152) EdgeNGramFilterFactory deletes token
[
https://issues.apache.org/jira/browse/SOLR-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher resolved SOLR-5152.
Resolution: Duplicate
> EdgeNGramFilterFactory deletes token
>
>
> Key: SOLR-5152
> URL: https://issues.apache.org/jira/browse/SOLR-5152
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.4
>Reporter: Christoph Lingg
>Priority: Major
> Attachments: SOLR-5152-v5.0.0.patch, SOLR-5152.patch
>
>
> I am using EdgeNGramFilterFactory in my schema.xml
> {code:xml} positionIncrementGap="100">
>
>
> maxGramSize="10" side="front" />
>
> {code}
> Some tokens in my index only consist of one character, let's say {{R}}.
> minGramSize is set to 2 and is bigger than the length of the token. I
> expected the NGramFilter to left {{R}} unchanged but in fact it is deleting
> the token.
> For my use case this interpretation is undesirable, and probably for most use
> cases too!?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3567) Spellcheck custom parameters not being passed through due to wrong prefix creation
[ https://issues.apache.org/jira/browse/SOLR-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499139#comment-16499139 ] Erik Hatcher commented on SOLR-3567: This is an interesting one that points out that test cases would perhaps be more useful if the string constants weren't used in them. Such that the test case would refer to literally "the.parameter.fully.as.a.string", and this issue would have been caught right away at dev time? Using literal strings would catch changes to the API that would break clients but would have kept test cases passing. Come to think of it, I think this one has bit me and had me scratching my head over spellchecking misbehaviors much in the past. Ugh. Good catch. > Spellcheck custom parameters not being passed through due to wrong prefix > creation > -- > > Key: SOLR-3567 > URL: https://issues.apache.org/jira/browse/SOLR-3567 > Project: Solr > Issue Type: Bug > Components: spellchecker >Affects Versions: 4.0-ALPHA >Reporter: josh lucas >Assignee: Shalin Shekhar Mangar >Priority: Major > Labels: patch, spellchecker > Fix For: 7.4, master (8.0) > > Attachments: SOLR-3567.patch, SOLR-3567.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11358) Support DelimitedTermFrequencyTokenFilter out of the box with dynamic field mapping
[ https://issues.apache.org/jira/browse/SOLR-11358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-11358: Summary: Support DelimitedTermFrequencyTokenFilter out of the box with dynamic field mapping (was: Support DelimitedTermFrequencyTokenFilter-using fields with payload() function) > Support DelimitedTermFrequencyTokenFilter out of the box with dynamic field > mapping > --- > > Key: SOLR-11358 > URL: https://issues.apache.org/jira/browse/SOLR-11358 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Major > Attachments: SOLR-11358.patch > > > payload() works values encoded with DelimitedPayloadTokenFilter. payload() > can be modified to return the term frequency instead, when the field uses > DelimitedTermFrequencyTokenFilter. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11358) Support DelimitedTermFrequencyTokenFilter-using fields with payload() function
[
https://issues.apache.org/jira/browse/SOLR-11358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479349#comment-16479349
]
Erik Hatcher commented on SOLR-11358:
-
{quote}Lets not bloat it?
{quote}
The default schema has dynamic field mapping for every language Solr supports
and bunch of other dynamic fields including the payload float/string/int ones.
Surely this one is ok to add too?
> Support DelimitedTermFrequencyTokenFilter-using fields with payload() function
> --
>
> Key: SOLR-11358
> URL: https://issues.apache.org/jira/browse/SOLR-11358
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Major
> Attachments: SOLR-11358.patch
>
>
> payload() works values encoded with DelimitedPayloadTokenFilter. payload()
> can be modified to return the term frequency instead, when the field uses
> DelimitedTermFrequencyTokenFilter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11358) Support DelimitedTermFrequencyTokenFilter-using fields with payload() function
[
https://issues.apache.org/jira/browse/SOLR-11358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479196#comment-16479196
]
Erik Hatcher commented on SOLR-11358:
-
Coming back to this, and double-checking the test cases and implementation, I
question whether this is really useful, to have `payload()` return the same
value that `termfreq()` would.
At least let's add:
{{ }}
{{ }}{{ }}
{{ }}
{{ }}{{ }}
{{ }}{{
}}
{{ }}
to the default managed-schema.
I could see it being handy if you're testing the difference between *_dpi and
*_dtf performance and potentially toggling back and forth and want it to be
transparent, but these delimited tf fields aren't going to work as if they were
truly payloaded with the payload scoring queries currently.
Thoughts?
> Support DelimitedTermFrequencyTokenFilter-using fields with payload() function
> --
>
> Key: SOLR-11358
> URL: https://issues.apache.org/jira/browse/SOLR-11358
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Major
> Attachments: SOLR-11358.patch
>
>
> payload() works values encoded with DelimitedPayloadTokenFilter. payload()
> can be modified to return the term frequency instead, when the field uses
> DelimitedTermFrequencyTokenFilter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11358) Support DelimitedTermFrequencyTokenFilter-using fields with payload() function
[
https://issues.apache.org/jira/browse/SOLR-11358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479196#comment-16479196
]
Erik Hatcher edited comment on SOLR-11358 at 5/17/18 3:18 PM:
--
Coming back to this, and double-checking the test cases and implementation, I
question whether this is really useful, to have `payload()` return the same
value that `termfreq()` would.
At least let's add:
{{ }}
{{ }}{{ }}
{{ }}
{{ }}
{{ }}{{
}}
{{ }}
to the default managed-schema.
I could see it being handy if you're testing the difference between *_dpi and
*_dtf performance and potentially toggling back and forth and want it to be
transparent, but these delimited tf fields aren't going to work as if they were
truly payloaded with the payload scoring queries currently.
Thoughts?
was (Author: ehatcher):
Coming back to this, and double-checking the test cases and implementation, I
question whether this is really useful, to have `payload()` return the same
value that `termfreq()` would.
At least let's add:
{{ }}
{{ }}{{ }}
{{ }}
{{ }}{{ }}
{{ }}{{
}}
{{ }}
to the default managed-schema.
I could see it being handy if you're testing the difference between *_dpi and
*_dtf performance and potentially toggling back and forth and want it to be
transparent, but these delimited tf fields aren't going to work as if they were
truly payloaded with the payload scoring queries currently.
Thoughts?
> Support DelimitedTermFrequencyTokenFilter-using fields with payload() function
> --
>
> Key: SOLR-11358
> URL: https://issues.apache.org/jira/browse/SOLR-11358
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Major
> Attachments: SOLR-11358.patch
>
>
> payload() works values encoded with DelimitedPayloadTokenFilter. payload()
> can be modified to return the term frequency instead, when the field uses
> DelimitedTermFrequencyTokenFilter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12238) Synonym Query Style Boost By Payload
[
https://issues.apache.org/jira/browse/SOLR-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456976#comment-16456976
]
Erik Hatcher commented on SOLR-12238:
-
{quote}Applying this at indexing time should imply a modification in the
similarity function
{quote}
SOLR-1485 provides the solution to this one, with additional query parsers
(`payload_score` in this case) and `payload()` function query.
> Synonym Query Style Boost By Payload
>
>
> Key: SOLR-12238
> URL: https://issues.apache.org/jira/browse/SOLR-12238
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.2
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: SOLR-12238.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This improvement is built on top of the Synonym Query Style feature and
> brings the possibility of boosting synonym queries using the payload
> associated.
> It introduces two new modalities for the Synonym Query Style :
> PICK_BEST_BOOST_BY_PAYLOAD -> build a Disjunction query with the clauses
> boosted by payload
> AS_DISTINCT_TERMS_BOOST_BY_PAYLOAD -> build a Boolean query with the clauses
> boosted by payload
> This new synonym query styles will assume payloads are available so they must
> be used in conjunction with a token filter able to produce payloads.
> An synonym.txt example could be :
> # Synonyms used by Payload Boost
> tiger => tiger|1.0, Big_Cat|0.8, Shere_Khan|0.9
> leopard => leopard, Big_Cat|0.8, Bagheera|0.9
> lion => lion|1.0, panthera leo|0.99, Simba|0.8
> snow_leopard => panthera uncia|0.99, snow leopard|1.0
> A simple token filter to populate the payloads from such synonym.txt is :
> delimiter="|"/>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12238) Synonym Query Style Boost By Payload
[ https://issues.apache.org/jira/browse/SOLR-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452908#comment-16452908 ] Erik Hatcher commented on SOLR-12238: - [~alessandro.benedetti] - great trick, putting delimited weights on synonyms. A couple of questions: does this also work with index-time synonyms? (I don't think so, since the delimiters cause issues with synonym matching), and does this work with ManagedSynonymGraphFilterFactory? > Synonym Query Style Boost By Payload > > > Key: SOLR-12238 > URL: https://issues.apache.org/jira/browse/SOLR-12238 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Reporter: Alessandro Benedetti >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This improvement is built on top of the Synonym Query Style feature and > brings the possibility of boosting synonym queries using the payload > associated. > It introduces two new modalities for the Synonym Query Style : > PICK_BEST_BOOST_BY_PAYLOAD -> build a Disjunction query with the clauses > boosted by payload > AS_DISTINCT_TERMS_BOOST_BY_PAYLOAD -> build a Boolean query with the clauses > boosted by payload > This new synonym query styles will assume payloads are available so they must > be used in conjunction with a token filter able to produce payloads. > An synonym.txt example could be : > # Synonyms used by Payload Boost > tiger => tiger|1.0, Big_Cat|0.8, Shere_Khan|0.9 > leopard => leopard, Big_Cat|0.8, Bagheera|0.9 > lion => lion|1.0, panthera leo|0.99, Simba|0.8 > snow_leopard => panthera uncia|0.99, snow leopard|1.0 > A simple token filter to populate the payloads from such synonym.txt is : > delimiter="|"/> -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10874) AIOOBE when FloatPayloadValueSource calls floatVal() for the same doc id more than once
[ https://issues.apache.org/jira/browse/SOLR-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16220302#comment-16220302 ] Erik Hatcher commented on SOLR-10874: - [~steve_rowe] - thanks for the test on this - +1 all aound. Apologies, Michael et al, for letting this slip. > AIOOBE when FloatPayloadValueSource calls floatVal() for the same doc id more > than once > --- > > Key: SOLR-10874 > URL: https://issues.apache.org/jira/browse/SOLR-10874 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 6.6, 7.0, 7.0.1, 7.1 >Reporter: Michael Kosten >Assignee: Erik Hatcher >Priority: Minor > Attachments: SOLR-10874.patch, SOLR-10874.patch, SOLR-10874.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Using the new payload function will fail with an assertion error if the debug > parameter is included in the query. This is caused by the floatValue method > in FloatPayloadValueSource being called for the same doc id twice in a row. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11358) Support DelimitedTermFrequencyTokenFilter-using fields with payload() function
[ https://issues.apache.org/jira/browse/SOLR-11358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-11358: Attachment: SOLR-11358.patch Here's a quick and dirty functional patch > Support DelimitedTermFrequencyTokenFilter-using fields with payload() function > -- > > Key: SOLR-11358 > URL: https://issues.apache.org/jira/browse/SOLR-11358 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Attachments: SOLR-11358.patch > > > payload() works values encoded with DelimitedPayloadTokenFilter. payload() > can be modified to return the term frequency instead, when the field uses > DelimitedTermFrequencyTokenFilter. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11358) Support DelimitedTermFrequencyTokenFilter-using fields with payload() function
Erik Hatcher created SOLR-11358: --- Summary: Support DelimitedTermFrequencyTokenFilter-using fields with payload() function Key: SOLR-11358 URL: https://issues.apache.org/jira/browse/SOLR-11358 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Erik Hatcher Assignee: Erik Hatcher payload() works values encoded with DelimitedPayloadTokenFilter. payload() can be modified to return the term frequency instead, when the field uses DelimitedTermFrequencyTokenFilter. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11199) Support OR queries in the Payload Score Parser
[ https://issues.apache.org/jira/browse/SOLR-11199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119966#comment-16119966 ] Erik Hatcher commented on SOLR-11199: - Nice work Varun! Both `sum` and `phrase`/`or` - handy improvements! > Support OR queries in the Payload Score Parser > --- > > Key: SOLR-11199 > URL: https://issues.apache.org/jira/browse/SOLR-11199 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Varun Thacker > Fix For: master (8.0), 7.1 > > Attachments: SOLR-11199.patch, SOLR-11199.patch > > > PayloadScoreQParserPlugin always creates a SpanNearQuery. > In my use-case I want to be able to do an OR query and then use a sum > function to sum up all the scores. > So if the PayloadScoreQParserPlugin supported an operator param which could > be used to pick between phrase searches ( the default currently ) OR and ANDs -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11199) Support OR queries in the Payload Score Parser
[ https://issues.apache.org/jira/browse/SOLR-11199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114885#comment-16114885 ] Erik Hatcher commented on SOLR-11199: - Yeah, the SpanNearQuery approach was really just the first pass until something better and more flexible came along to create SpanQuery's from some (likely) payloaded terms. > Support OR queries in the Payload Score Parser > --- > > Key: SOLR-11199 > URL: https://issues.apache.org/jira/browse/SOLR-11199 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker > > PayloadScoreQParserPlugin always creates a SpanNearQuery. > In my use-case I want to be able to do an OR query and then use a sum > function to sum up all the scores. > So if the PayloadScoreQParserPlugin supported an operator param which could > be used to pick between phrase searches ( the default currently ) OR and ANDs -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2997) PayloadQueryParser addition
[
https://issues.apache.org/jira/browse/LUCENE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16060837#comment-16060837
]
Erik Hatcher commented on LUCENE-2997:
--
[~edwardd] - long time, sorry!Do you think the new `{!payload_score}`
qparser now suffices?
> PayloadQueryParser addition
> ---
>
> Key: LUCENE-2997
> URL: https://issues.apache.org/jira/browse/LUCENE-2997
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/queryparser, modules/other
>Affects Versions: 3.0.1
> Environment: n/a
>Reporter: Edward Drapkin
>Assignee: Erik Hatcher
> Labels: dead, features, patch
> Fix For: 4.9, 6.0
>
> Attachments: PayloadQueryParser.java
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> I recently needed to deploy payloads for my search system and ran into a
> small wall: there was no query parser available for use with Payloads. I
> through this one together, extending out of the new modular QueryParser
> structure.
> Attached is the class file. I didn't know what package this would belong in
> (whether with the query parser or with the rest of the payload functionality
> in contrib/analyzers), so it's in the default package for now.
> I know this is a little, simple thing, but it seemed like something that
> should probably be included.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10909) Cannot sort by function
[
https://issues.apache.org/jira/browse/SOLR-10909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052757#comment-16052757
]
Erik Hatcher commented on SOLR-10909:
-
Commas not semicolons?
> Cannot sort by function
>
>
> Key: SOLR-10909
> URL: https://issues.apache.org/jira/browse/SOLR-10909
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 6.4.1
> Environment: ubuntu 14.4
>Reporter: David Liu
>
> I have two fields in my solr schema: *solr_weight* and *brand*, I want to
> implement one query which can dynamically put all brand=XX data in first, and
> then show others and sort by solr_weight,
> so, I use *if* and *sum* function in solr sort to do it, however, looks like
> a bug because *if* doesn't work in sort
> {quote}sort=if(brand=="3701"; sum(solr_weight,25); solr_weight )
> desc{quote}
> {quote}ERROR: "msg":"Can't determine a Sort Order (asc or desc) in sort spec
> 'if(brand==\"3701\"; sum(solr_weight,25); solr_weight ;) desc',
> pos=19",{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10874) FloatPayloadValueSource throws assertion error if debug=true
[ https://issues.apache.org/jira/browse/SOLR-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049179#comment-16049179 ] Erik Hatcher commented on SOLR-10874: - bq. Maybe this scenario only happens in very specific circumstances? What are your circumstances outside of this test case? I'd just like to experience it in the wild - I'll get the fix committed, ideally before for a 6.6.1 or 6.7. I tried with a single doc indexed to see if it had to do with only one document, but still didn't fail to work as expected though the test case definitely fails - my bad. > FloatPayloadValueSource throws assertion error if debug=true > > > Key: SOLR-10874 > URL: https://issues.apache.org/jira/browse/SOLR-10874 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 6.6 >Reporter: Michael Kosten >Assignee: Erik Hatcher >Priority: Minor > Fix For: master (7.0), 6.7, 6.6.1 > > Attachments: SOLR-10874.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Using the new payload function will fail with an assertion error if the debug > parameter is included in the query. This is caused by the floatValue method > in FloatPayloadValueSource being called for the same doc id twice in a row. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-10874) FloatPayloadValueSource throws assertion error if debug=true
[ https://issues.apache.org/jira/browse/SOLR-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned SOLR-10874: --- Assignee: Erik Hatcher > FloatPayloadValueSource throws assertion error if debug=true > > > Key: SOLR-10874 > URL: https://issues.apache.org/jira/browse/SOLR-10874 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 6.6 >Reporter: Michael Kosten >Assignee: Erik Hatcher >Priority: Minor > Fix For: master (7.0), 6.7, 6.6.1 > > Attachments: SOLR-10874.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Using the new payload function will fail with an assertion error if the debug > parameter is included in the query. This is caused by the floatValue method > in FloatPayloadValueSource being called for the same doc id twice in a row. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10874) FloatPayloadValueSource throws assertion error if debug=true
[ https://issues.apache.org/jira/browse/SOLR-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-10874: Fix Version/s: 6.6.1 6.7 master (7.0) > FloatPayloadValueSource throws assertion error if debug=true > > > Key: SOLR-10874 > URL: https://issues.apache.org/jira/browse/SOLR-10874 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 6.6 >Reporter: Michael Kosten >Priority: Minor > Fix For: master (7.0), 6.7, 6.6.1 > > Attachments: SOLR-10874.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Using the new payload function will fail with an assertion error if the debug > parameter is included in the query. This is caused by the floatValue method > in FloatPayloadValueSource being called for the same doc id twice in a row. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10874) FloatPayloadValueSource throws assertion error if debug=true
[
https://issues.apache.org/jira/browse/SOLR-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047913#comment-16047913
]
Erik Hatcher commented on SOLR-10874:
-
[~makos...@me.com] ouch! investigating through a test case, but I am not
seeing it outside the test case. I'm trying it like this:
[http://localhost:/solr/payloads/query?q=\{!func}payload(vals_dpf,one)=*,score=true=id:(1%202)]
{code}
{
"responseHeader":{
"status":0,
"QTime":4,
"params":{
"q":"{!func}payload(vals_dpf,one)",
"debug":"true",
"fl":"*,score",
"fq":"id:(1 2)"}},
"response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
{
"id":"1",
"vals_dpf":"one|1.0 two|2.0 three|3.0",
"_version_":1569489972428275712,
"score":1.0},
{
"id":"2",
"vals_dpf":"weighted|50.0 weighted|100.0",
"_version_":1569489972431421440,
"score":0.0}]
},
"debug":{
"rawquerystring":"{!func}payload(vals_dpf,one)",
"querystring":"{!func}payload(vals_dpf,one)",
"parsedquery":"FunctionQuery(payload(vals_dpf,one,const(0.0)))",
"parsedquery_toString":"payload(vals_dpf,one,const(0.0))",
"explain":{
"1":"\n1.0 = FunctionQuery(payload(vals_dpf,one,const(0.0))), product
of:\n 0.0 = payload(vals_dpf,one,const(0.0))=0.0\n 1.0 = boost\n 1.0 =
queryNorm\n",
"2":"\n0.0 = FunctionQuery(payload(vals_dpf,one,const(0.0))), product
of:\n 0.0 = payload(vals_dpf,one,const(0.0))=0.0\n 1.0 = boost\n 1.0 =
queryNorm\n"},
"QParser":"FunctionQParser",
"filter_queries":["id:(1 2)"],
"parsed_filter_queries":["id:1 id:2"],
"timing":{
"time":4.0,
"prepare":{
"time":2.0,
"query":{
"time":2.0},
"facet":{
"time":0.0},
"facet_module":{
"time":0.0},
"mlt":{
"time":0.0},
"highlight":{
"time":0.0},
"stats":{
"time":0.0},
"expand":{
"time":0.0},
"terms":{
"time":0.0},
"debug":{
"time":0.0}},
"process":{
"time":1.0,
"query":{
"time":0.0},
"facet":{
"time":0.0},
"facet_module":{
"time":0.0},
"mlt":{
"time":0.0},
"highlight":{
"time":0.0},
"stats":{
"time":0.0},
"expand":{
"time":0.0},
"terms":{
"time":0.0},
"debug":{
"time":1.0}
{code}
> FloatPayloadValueSource throws assertion error if debug=true
>
>
> Key: SOLR-10874
> URL: https://issues.apache.org/jira/browse/SOLR-10874
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Affects Versions: 6.6
>Reporter: Michael Kosten
>Priority: Minor
> Attachments: SOLR-10874.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Using the new payload function will fail with an assertion error if the debug
> parameter is included in the query. This is caused by the floatValue method
> in FloatPayloadValueSource being called for the same doc id twice in a row.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10876) Regression in loading runtime UpdateRequestProcessors
[ https://issues.apache.org/jira/browse/SOLR-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-10876: Affects Version/s: 6.6 > Regression in loading runtime UpdateRequestProcessors > - > > Key: SOLR-10876 > URL: https://issues.apache.org/jira/browse/SOLR-10876 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-10876.patch > > > This was introduced as a part of SOLR-9530 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10869) Make StatelessScriptUpdateProcessorFactory as Runtime URP; take params(s) with request
[
https://issues.apache.org/jira/browse/SOLR-10869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16045905#comment-16045905
]
Erik Hatcher commented on SOLR-10869:
-
bq. So the initEngines(...) is called at inform(...) to validate the scripts at
startup of core and there's no other motive to it?
Looks like it, yeah.
I think the parameter prefix is best as "script" rather than "statelessscript".
"script.script" is funny though, so maybe it should be "script.file"?
> Make StatelessScriptUpdateProcessorFactory as Runtime URP; take params(s)
> with request
> --
>
> Key: SOLR-10869
> URL: https://issues.apache.org/jira/browse/SOLR-10869
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs
> and take parameters in the request itself.
> StatelessScriptUpdateProcessorFactory will be able to execute by sample curl
> like below:
> {code}
> curl -X POST -H Content-Type: application/json
> http://localhost:8983/solr/test/update/json/docs?processor=StatelessScript=1.js=2.js=3.js=keyA:valueA=keyB:valueB=keyC:valueC=true
> --data-binary { "id" : "1" , "title_s" : "title_random" }
> {code}
> All the param(s) for this URP available can be passed as request handler
> param(s). The scripts will be executed in the order the parameters are
> received.
> Configuration for StatelessScriptUpdateProcessorFactory in solrconfig.xml is
> optional. Backcompat is intact.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7500) Remove Fields.java in lieu of LeafReader.getTerms(fieldName)
[
https://issues.apache.org/jira/browse/LUCENE-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated LUCENE-7500:
-
Summary: Remove Fields.java in lieu of LeafReader.getTerms(fieldName)
(was: Nuke Fields.java in lieu of LeafReader.getTerms(fieldName))
> Remove Fields.java in lieu of LeafReader.getTerms(fieldName)
>
>
> Key: LUCENE-7500
> URL: https://issues.apache.org/jira/browse/LUCENE-7500
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7500_avoid_leafReader_fields.patch,
> LUCENE_7500_avoid_leafReader_fields.patch,
> LUCENE_7500_Remove_LeafReader_fields.patch,
> LUCENE_7500_Remove_LeafReader_fields.patch
>
>
> {{Fields}} seems like a pointless intermediary between the {{LeafReader}} and
> {{Terms}}. Why not have {{LeafReader.getTerms(fieldName)}} instead? One loses
> the ability to get the count and iterate over indexed fields, but it's not
> clear what real use-cases are for that and such rare needs could figure that
> out with FieldInfos.
> [~mikemccand] pointed out that we'd probably need to re-introduce a
> {{TermVectors}} class since TV's are row-oriented not column-oriented. IMO
> they should be column-oriented but that'd be a separate issue.
> _(p.s. I'm lacking time to do this w/i the next couple months so if someone
> else wants to tackle it then great)_
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10789) SpellCheckCollator prohibits setting several query parser params
[ https://issues.apache.org/jira/browse/SOLR-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16031599#comment-16031599 ] Erik Hatcher commented on SOLR-10789: - Surely it wasn't intentional to prohibit any `pf` to be used with collation queries - and the logic to remove params should be moved above the override to allow explicit setting of these parameters for collation query customization. > SpellCheckCollator prohibits setting several query parser params > > > Key: SOLR-10789 > URL: https://issues.apache.org/jira/browse/SOLR-10789 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erik Hatcher > Fix For: master (7.0) > > > SpellCheckCollator eats tie, pf, pf2, pf3, bq, and bf. > There is a mechanism to allow the collator to inherit global params, and > override them even (via `spellcheck.collateParam.*`), but then it eats the > aforementioned ones regardless. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10789) SpellCheckCollator prohibits setting several query parser params
[ https://issues.apache.org/jira/browse/SOLR-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-10789: Fix Version/s: master (7.0) > SpellCheckCollator prohibits setting several query parser params > > > Key: SOLR-10789 > URL: https://issues.apache.org/jira/browse/SOLR-10789 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erik Hatcher > Fix For: master (7.0) > > > SpellCheckCollator eats tie, pf, pf2, pf3, bq, and bf. > There is a mechanism to allow the collator to inherit global params, and > override them even (via `spellcheck.collateParam.*`), but then it eats the > aforementioned ones regardless. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10789) SpellCheckCollator prohibits setting several query parser params
Erik Hatcher created SOLR-10789: --- Summary: SpellCheckCollator prohibits setting several query parser params Key: SOLR-10789 URL: https://issues.apache.org/jira/browse/SOLR-10789 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Erik Hatcher SpellCheckCollator eats tie, pf, pf2, pf3, bq, and bf. There is a mechanism to allow the collator to inherit global params, and override them even (via `spellcheck.collateParam.*`), but then it eats the aforementioned ones regardless. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7848) QueryBuilder.analyzeGraphPhrase does not handle gaps correctly
[ https://issues.apache.org/jira/browse/LUCENE-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021368#comment-16021368 ] Erik Hatcher edited comment on LUCENE-7848 at 5/23/17 3:57 PM: --- I hit a snag with QueryBuilder#createSpanQuery too, and created (for the SOLR-1485 work) org.apache.solr.util.PayloadUtils with a createSpanQuery method. It currently also doesn't take gaps into account (but the basic use cases don't involve sophisticated analysis there, so it was intentional to keep it initially simple), but I did have to work through some Lucene analysis API hurdles that I think QueryBuilder's createSpanQuery should fix along the way too. See my comment and implementation here: https://github.com/apache/lucene-solr/blob/5d42177b9290b61c658154e42223408944cd4bc1/solr/core/src/java/org/apache/solr/util/PayloadUtils.java#L106-L128 was (Author: ehatcher): I hit a snag with QueryBuilder#createSpanQuery too, and created (for the SOLR-1485 work) org.apache.solr.util.PayloadUtils with a createSpanQuery method. It currently also doesn't take into account for gaps (but the basic use cases don't involve sophisticated analysis there, so it was intentional to keep it initially simple), but I did have to work through some Lucene analysis API hurdles that I think QueryBuilder's createSpanQuery should fix along the way too. See my comment and implementation here: https://github.com/apache/lucene-solr/blob/5d42177b9290b61c658154e42223408944cd4bc1/solr/core/src/java/org/apache/solr/util/PayloadUtils.java#L106-L128 > QueryBuilder.analyzeGraphPhrase does not handle gaps correctly > -- > > Key: LUCENE-7848 > URL: https://issues.apache.org/jira/browse/LUCENE-7848 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.5, 6.6 >Reporter: Jim Ferenczi > > Position increments greater than 1 are ignored when the query builder creates > a graph phrase query. > Instead it should use SpanNearQuery.addGap for pos incr > 1. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7699) Apply graph articulation points optimization to phrase graph queries
[ https://issues.apache.org/jira/browse/LUCENE-7699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated LUCENE-7699: - Fix Version/s: 6.5 > Apply graph articulation points optimization to phrase graph queries > > > Key: LUCENE-7699 > URL: https://issues.apache.org/jira/browse/LUCENE-7699 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Matt Weber >Assignee: Jim Ferenczi > Fix For: 6.5 > > Attachments: LUCENE-7699.patch, LUCENE-7699.patch > > > Follow-up to LUCENE-7638 that applies the same articulation point logic to > graph phrases using span queries. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-7699) Apply graph articulation points optimization to phrase graph queries
[ https://issues.apache.org/jira/browse/LUCENE-7699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reopened LUCENE-7699: -- Assignee: Jim Ferenczi re-opening to add fix version > Apply graph articulation points optimization to phrase graph queries > > > Key: LUCENE-7699 > URL: https://issues.apache.org/jira/browse/LUCENE-7699 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Matt Weber >Assignee: Jim Ferenczi > Fix For: 6.5 > > Attachments: LUCENE-7699.patch, LUCENE-7699.patch > > > Follow-up to LUCENE-7638 that applies the same articulation point logic to > graph phrases using span queries. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7699) Apply graph articulation points optimization to phrase graph queries
[ https://issues.apache.org/jira/browse/LUCENE-7699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved LUCENE-7699. -- Resolution: Fixed > Apply graph articulation points optimization to phrase graph queries > > > Key: LUCENE-7699 > URL: https://issues.apache.org/jira/browse/LUCENE-7699 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Matt Weber >Assignee: Jim Ferenczi > Fix For: 6.5 > > Attachments: LUCENE-7699.patch, LUCENE-7699.patch > > > Follow-up to LUCENE-7638 that applies the same articulation point logic to > graph phrases using span queries. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7638) Optimize graph query produced by QueryBuilder
[ https://issues.apache.org/jira/browse/LUCENE-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021381#comment-16021381 ] Erik Hatcher commented on LUCENE-7638: -- [~mbraun688] looks like from CHANGES and commits this was 6.5 so I marked it as so. > Optimize graph query produced by QueryBuilder > - > > Key: LUCENE-7638 > URL: https://issues.apache.org/jira/browse/LUCENE-7638 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi > Fix For: 6.5 > > Attachments: LUCENE-7638.patch, LUCENE-7638.patch > > > The QueryBuilder creates a graph query when the underlying TokenStream > contains token with PositionLengthAttribute greater than 1. > These TokenStreams are in fact graphs (lattice to be more precise) where > synonyms can span on multiple terms. > Currently the graph query is built by visiting all the path of the graph > TokenStream. For instance if you have a synonym like "ny, new york" and you > search for "new york city", the query builder would produce two pathes: > "new york city", "ny city" > This can quickly explode when the number of multi terms synonyms increase. > The query "ny ny" for instance would produce 4 pathes and so on. > For boolean queries with should or must clauses it should be more efficient > to build a boolean query that merges all the intersections in the graph. So > instead of "new york city", "ny city" we could produce: > "+((+new +york) ny) +city" > The attached patch is a proposal to do that instead of the all path solution. > The patch transforms multi terms synonyms in graph query for each > intersection in the graph. This is not done in this patch but we could also > create a specialized query that gives equivalent scores to multi terms > synonyms like the SynonymQuery does for single term synonyms. > For phrase query this patch does not change the current behavior but we could > also use the new method to create optimized graph SpanQuery. > [~mattweber] I think this patch could optimize a lot of cases where multiple > muli-terms synonyms are present in a single request. Could you take a look ? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7638) Optimize graph query produced by QueryBuilder
[ https://issues.apache.org/jira/browse/LUCENE-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated LUCENE-7638: - Fix Version/s: 6.5 > Optimize graph query produced by QueryBuilder > - > > Key: LUCENE-7638 > URL: https://issues.apache.org/jira/browse/LUCENE-7638 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi > Fix For: 6.5 > > Attachments: LUCENE-7638.patch, LUCENE-7638.patch > > > The QueryBuilder creates a graph query when the underlying TokenStream > contains token with PositionLengthAttribute greater than 1. > These TokenStreams are in fact graphs (lattice to be more precise) where > synonyms can span on multiple terms. > Currently the graph query is built by visiting all the path of the graph > TokenStream. For instance if you have a synonym like "ny, new york" and you > search for "new york city", the query builder would produce two pathes: > "new york city", "ny city" > This can quickly explode when the number of multi terms synonyms increase. > The query "ny ny" for instance would produce 4 pathes and so on. > For boolean queries with should or must clauses it should be more efficient > to build a boolean query that merges all the intersections in the graph. So > instead of "new york city", "ny city" we could produce: > "+((+new +york) ny) +city" > The attached patch is a proposal to do that instead of the all path solution. > The patch transforms multi terms synonyms in graph query for each > intersection in the graph. This is not done in this patch but we could also > create a specialized query that gives equivalent scores to multi terms > synonyms like the SynonymQuery does for single term synonyms. > For phrase query this patch does not change the current behavior but we could > also use the new method to create optimized graph SpanQuery. > [~mattweber] I think this patch could optimize a lot of cases where multiple > muli-terms synonyms are present in a single request. Could you take a look ? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7848) QueryBuilder.analyzeGraphPhrase does not handle gaps correctly
[ https://issues.apache.org/jira/browse/LUCENE-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021368#comment-16021368 ] Erik Hatcher commented on LUCENE-7848: -- I hit a snag with QueryBuilder#createSpanQuery too, and created (for the SOLR-1485 work) org.apache.solr.util.PayloadUtils with a createSpanQuery method. It currently also doesn't take into account for gaps (but the basic use cases don't involve sophisticated analysis there, so it was intentional to keep it initially simple), but I did have to work through some Lucene analysis API hurdles that I think QueryBuilder's createSpanQuery should fix along the way too. See my comment and implementation here: https://github.com/apache/lucene-solr/blob/5d42177b9290b61c658154e42223408944cd4bc1/solr/core/src/java/org/apache/solr/util/PayloadUtils.java#L106-L128 > QueryBuilder.analyzeGraphPhrase does not handle gaps correctly > -- > > Key: LUCENE-7848 > URL: https://issues.apache.org/jira/browse/LUCENE-7848 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.5, 6.6 >Reporter: Jim Ferenczi > > Position increments greater than 1 are ignored when the query builder creates > a graph phrase query. > Instead it should use SpanNearQuery.addGap for pos incr > 1. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5008) Add Support for composite CSV fields
[ https://issues.apache.org/jira/browse/SOLR-5008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16018230#comment-16018230 ] Erik Hatcher commented on SOLR-5008: [~gsingers] does `TemplateUpdateProcessor` solve this one? > Add Support for composite CSV fields > > > Key: SOLR-5008 > URL: https://issues.apache.org/jira/browse/SOLR-5008 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Priority: Minor > Fix For: 4.9, 6.0 > > > It is often useful to be able to create a single field from more than one CSV > column. For instance, I may want to take a latitude and longitude column in > my CSV and map that to a single field name -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8035) Move solr/webapp to solr/server/solr-webapp
[ https://issues.apache.org/jira/browse/SOLR-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-8035: --- Fix Version/s: (was: 6.0) master (7.0) > Move solr/webapp to solr/server/solr-webapp > --- > > Key: SOLR-8035 > URL: https://issues.apache.org/jira/browse/SOLR-8035 > Project: Solr > Issue Type: Bug > Components: Admin UI >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: master (7.0) > > Attachments: SOLR-8035.patch > > > Let's move solr/webapp *source* files to their final actual distro > destination. This facilitates folks editing the UI in real-time (save > change, refresh in browser) rather than having to "stop, ant server, restart" > to see a change. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5635) Payloads malfunctioning in basic use case
[ https://issues.apache.org/jira/browse/SOLR-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved SOLR-5635. Resolution: Fixed closing this one as SOLR-1485 covers it, I think. > Payloads malfunctioning in basic use case > - > > Key: SOLR-5635 > URL: https://issues.apache.org/jira/browse/SOLR-5635 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6 >Reporter: michael boom >Assignee: Erik Hatcher > > This issue is also discussed on the mailing list: > http://lucene.472066.n3.nabble.com/Simple-payloads-example-not-working-td4110998.html > It proved that for a term search, all documents would have the same score, > equal to the payload value of the first document: > - > http://localhost:8983/solr/collection1/pds-search?q=payloads:testone=json=true=true > with result: https://gist.github.com/maephisto/8433641 > I tried building a simple payloads example using the stock Solr/Lucene 4.6.0. > I created a custom similarity and a custom query parser - built my plugin and > tested it out. > collection1 schema.xml changes: https://gist.github.com/maephisto/8433537 > collection1 sorlconfig.xml changes: https://gist.github.com/maephisto/8433550 > custom similarity: https://gist.github.com/maephisto/8433263 > custom query parser: https://gist.github.com/maephisto/8433217 > documents added: https://gist.github.com/maephisto/8433719 > I tested it with Solr/Lucene4.6.0 stock example. The plugin was built using > NetBeans. > I used gists inside the ticket in order to keep the description shorter. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5635) Payloads malfunctioning in basic use case
[ https://issues.apache.org/jira/browse/SOLR-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-5635: --- Fix Version/s: master (7.0) 6.6 > Payloads malfunctioning in basic use case > - > > Key: SOLR-5635 > URL: https://issues.apache.org/jira/browse/SOLR-5635 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6 >Reporter: michael boom >Assignee: Erik Hatcher > Fix For: 6.6, master (7.0) > > > This issue is also discussed on the mailing list: > http://lucene.472066.n3.nabble.com/Simple-payloads-example-not-working-td4110998.html > It proved that for a term search, all documents would have the same score, > equal to the payload value of the first document: > - > http://localhost:8983/solr/collection1/pds-search?q=payloads:testone=json=true=true > with result: https://gist.github.com/maephisto/8433641 > I tried building a simple payloads example using the stock Solr/Lucene 4.6.0. > I created a custom similarity and a custom query parser - built my plugin and > tested it out. > collection1 schema.xml changes: https://gist.github.com/maephisto/8433537 > collection1 sorlconfig.xml changes: https://gist.github.com/maephisto/8433550 > custom similarity: https://gist.github.com/maephisto/8433263 > custom query parser: https://gist.github.com/maephisto/8433217 > documents added: https://gist.github.com/maephisto/8433719 > I tested it with Solr/Lucene4.6.0 stock example. The plugin was built using > NetBeans. > I used gists inside the ticket in order to keep the description shorter. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4719) Payloads per position broken
[ https://issues.apache.org/jira/browse/LUCENE-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16018214#comment-16018214 ] Erik Hatcher commented on LUCENE-4719: -- Is this still an open issue? Looks like it was re-opened but then it was a test code issue instead? > Payloads per position broken > > > Key: LUCENE-4719 > URL: https://issues.apache.org/jira/browse/LUCENE-4719 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: 4.1 >Reporter: André >Assignee: Robert Muir > Attachments: PayloadsTestCase.java > > > In 4.0 it worked. Since 4.1 getPayload() returns the same value for every > position of the same term. Additionally payloads stored on the term vector > (correct) may differ form payloads stored in the postings (wrong). -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-4721) WordDelimiterFilter ignores payloads
[ https://issues.apache.org/jira/browse/LUCENE-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned LUCENE-4721: Assignee: Erik Hatcher > WordDelimiterFilter ignores payloads > - > > Key: LUCENE-4721 > URL: https://issues.apache.org/jira/browse/LUCENE-4721 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Affects Versions: 4.1 >Reporter: Scott Smerchek >Assignee: Erik Hatcher > Attachments: LUCENE-4721.patch > > > When generating new tokens, the WordDelimeterFilter does not carry forward > payloads. It appears that this issue was fixed long ago in 1.4 > (https://issues.apache.org/jira/browse/SOLR-532), however, it is yet again an > issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2264) Add missing tests for PayloadXxxQuery
[ https://issues.apache.org/jira/browse/LUCENE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16018211#comment-16018211 ] Erik Hatcher commented on LUCENE-2264: -- [~thetaphi] I think the tests are sufficient now for the payload queries. Any gaps you see now? > Add missing tests for PayloadXxxQuery > - > > Key: LUCENE-2264 > URL: https://issues.apache.org/jira/browse/LUCENE-2264 > Project: Lucene - Core > Issue Type: Test > Components: core/search >Reporter: Uwe Schindler >Assignee: Erik Hatcher >Priority: Minor > Fix For: 4.9, 6.0 > > > This is a followup for LUCENE-1941 and the discussion in IRC. The Payload > queries have no real working tests, esp they are missing for the Min/Max/Avg > functions. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-2264) Add missing tests for PayloadXxxQuery
[ https://issues.apache.org/jira/browse/LUCENE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned LUCENE-2264: Assignee: Erik Hatcher > Add missing tests for PayloadXxxQuery > - > > Key: LUCENE-2264 > URL: https://issues.apache.org/jira/browse/LUCENE-2264 > Project: Lucene - Core > Issue Type: Test > Components: core/search >Reporter: Uwe Schindler >Assignee: Erik Hatcher >Priority: Minor > Fix For: 4.9, 6.0 > > > This is a followup for LUCENE-1941 and the discussion in IRC. The Payload > queries have no real working tests, esp they are missing for the Min/Max/Avg > functions. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-2997) PayloadQueryParser addition
[ https://issues.apache.org/jira/browse/LUCENE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned LUCENE-2997: Assignee: Erik Hatcher > PayloadQueryParser addition > --- > > Key: LUCENE-2997 > URL: https://issues.apache.org/jira/browse/LUCENE-2997 > Project: Lucene - Core > Issue Type: New Feature > Components: core/queryparser, modules/other >Affects Versions: 3.0.1 > Environment: n/a >Reporter: Edward Drapkin >Assignee: Erik Hatcher > Labels: dead, features, patch > Fix For: 4.9, 6.0 > > Attachments: PayloadQueryParser.java > > Original Estimate: 0h > Remaining Estimate: 0h > > I recently needed to deploy payloads for my search system and ran into a > small wall: there was no query parser available for use with Payloads. I > through this one together, extending out of the new modular QueryParser > structure. > Attached is the class file. I didn't know what package this would belong in > (whether with the query parser or with the rest of the payload functionality > in contrib/analyzers), so it's in the default package for now. > I know this is a little, simple thing, but it seemed like something that > should probably be included. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-7812) modified test for testing payload
[ https://issues.apache.org/jira/browse/LUCENE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned LUCENE-7812: Assignee: Erik Hatcher > modified test for testing payload > - > > Key: LUCENE-7812 > URL: https://issues.apache.org/jira/browse/LUCENE-7812 > Project: Lucene - Core > Issue Type: Test > Components: core/queryparser >Affects Versions: 6.5.1 > Environment: jdk 1.8 > mvn 3.3 >Reporter: Martin Gainty >Assignee: Erik Hatcher >Priority: Minor > Attachments: TestPayloadCheckQuery.java > > Original Estimate: 24h > Remaining Estimate: 24h > > no specific test for SpanPayloadCheckQuery method specifically > matches = payloadToMatch.get(upto).bytesEquals(payload); > the only implementation i could locate was in collectLeaf of > SpanPayloadCheckQuery > modified SpanPayloadCheckQueryTest now tests collectLeaf of > SpanPayloadCheckQuery > patch for test attached > suggestions/advice are most welcome -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-7744) default value for scoring payloads
[ https://issues.apache.org/jira/browse/LUCENE-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned LUCENE-7744: Assignee: Erik Hatcher > default value for scoring payloads > -- > > Key: LUCENE-7744 > URL: https://issues.apache.org/jira/browse/LUCENE-7744 > Project: Lucene - Core > Issue Type: New Feature > Components: core/query/scoring >Reporter: Nathan Gass >Assignee: Erik Hatcher >Priority: Minor > Fix For: master (7.0) > > > In lucene 5, PayloadTermQuery used a hardcoded default of 1.0 for terms > without a payload. The replacing PayloadScoreQuery in lucene 6 just ignores > those terms. This is unflexible and wrong for many use cases (for example > using Payloads to deemphasize some terms, where terms without payload should > result in maximum score instead of being ignored). > In my pull request I defer the decision on what to do with missing payloads > to the scorePayload method of the similarity, which has to check the given > payload for null and handle that case. I believe this breaks backwards > compatibility? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-7813) Force toString implementation for payload functions
[ https://issues.apache.org/jira/browse/LUCENE-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned LUCENE-7813: Assignee: Erik Hatcher > Force toString implementation for payload functions > --- > > Key: LUCENE-7813 > URL: https://issues.apache.org/jira/browse/LUCENE-7813 > Project: Lucene - Core > Issue Type: Task >Affects Versions: 6.5.1 >Reporter: Markus Jelsma >Assignee: Erik Hatcher >Priority: Trivial > Fix For: master (7.0) > > Attachments: LUCENE-7813.patch > > > Patch provides toString for payload functions. With this, queries and score > in debug output is better readable. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7744) default value for scoring payloads
[ https://issues.apache.org/jira/browse/LUCENE-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated LUCENE-7744: - Fix Version/s: master (7.0) > default value for scoring payloads > -- > > Key: LUCENE-7744 > URL: https://issues.apache.org/jira/browse/LUCENE-7744 > Project: Lucene - Core > Issue Type: New Feature > Components: core/query/scoring >Reporter: Nathan Gass >Priority: Minor > Fix For: master (7.0) > > > In lucene 5, PayloadTermQuery used a hardcoded default of 1.0 for terms > without a payload. The replacing PayloadScoreQuery in lucene 6 just ignores > those terms. This is unflexible and wrong for many use cases (for example > using Payloads to deemphasize some terms, where terms without payload should > result in maximum score instead of being ignored). > In my pull request I defer the decision on what to do with missing payloads > to the scorePayload method of the similarity, which has to check the given > payload for null and handle that case. I believe this breaks backwards > compatibility? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7975) Support payloads on primitive types
[ https://issues.apache.org/jira/browse/SOLR-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997155#comment-15997155 ] Erik Hatcher commented on SOLR-7975: [~jej2003] - blast from the not too distant past - I'm curious what use cases you have for this. Could you elaborate with some examples? With SOLR-1485, you can attach payloads and use them for numeric retrieval/weighting or PayloadCheckQuery matching - but it requires the right Query types to be used to leverage payload in scoring - what kinds of queries are you needing and what effect would payloads have on those queries? (are there Lucene query types already that satisfy your needs here?) > Support payloads on primitive types > --- > > Key: SOLR-7975 > URL: https://issues.apache.org/jira/browse/SOLR-7975 > Project: Solr > Issue Type: New Feature > Components: clients - java, Server >Reporter: Jamie Johnson > > Currently payloads are supported through the use of an analysis chain, this > limits the ability to provide payloads on primitive fields like Trie, Bool, > etc without copying these classes and adding the ability in custom code. It > would be great if payloads could be added to these field types in a pluggable > way similar to what is supported for non primitive types, perhaps through > extending the base primitive implementations. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5635) Payloads malfunctioning in basic use case
[ https://issues.apache.org/jira/browse/SOLR-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned SOLR-5635: -- Assignee: Erik Hatcher > Payloads malfunctioning in basic use case > - > > Key: SOLR-5635 > URL: https://issues.apache.org/jira/browse/SOLR-5635 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6 >Reporter: michael boom >Assignee: Erik Hatcher > > This issue is also discussed on the mailing list: > http://lucene.472066.n3.nabble.com/Simple-payloads-example-not-working-td4110998.html > It proved that for a term search, all documents would have the same score, > equal to the payload value of the first document: > - > http://localhost:8983/solr/collection1/pds-search?q=payloads:testone=json=true=true > with result: https://gist.github.com/maephisto/8433641 > I tried building a simple payloads example using the stock Solr/Lucene 4.6.0. > I created a custom similarity and a custom query parser - built my plugin and > tested it out. > collection1 schema.xml changes: https://gist.github.com/maephisto/8433537 > collection1 sorlconfig.xml changes: https://gist.github.com/maephisto/8433550 > custom similarity: https://gist.github.com/maephisto/8433263 > custom query parser: https://gist.github.com/maephisto/8433217 > documents added: https://gist.github.com/maephisto/8433719 > I tested it with Solr/Lucene4.6.0 stock example. The plugin was built using > NetBeans. > I used gists inside the ticket in order to keep the description shorter. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5635) Payloads malfunctioning in basic use case
[ https://issues.apache.org/jira/browse/SOLR-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997149#comment-15997149 ] Erik Hatcher commented on SOLR-5635: with SOLR-1485, the custom pieces here wouldn't be needed. I think we can close this one now? [~michael.boom] - thoughts? > Payloads malfunctioning in basic use case > - > > Key: SOLR-5635 > URL: https://issues.apache.org/jira/browse/SOLR-5635 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6 >Reporter: michael boom > > This issue is also discussed on the mailing list: > http://lucene.472066.n3.nabble.com/Simple-payloads-example-not-working-td4110998.html > It proved that for a term search, all documents would have the same score, > equal to the payload value of the first document: > - > http://localhost:8983/solr/collection1/pds-search?q=payloads:testone=json=true=true > with result: https://gist.github.com/maephisto/8433641 > I tried building a simple payloads example using the stock Solr/Lucene 4.6.0. > I created a custom similarity and a custom query parser - built my plugin and > tested it out. > collection1 schema.xml changes: https://gist.github.com/maephisto/8433537 > collection1 sorlconfig.xml changes: https://gist.github.com/maephisto/8433550 > custom similarity: https://gist.github.com/maephisto/8433263 > custom query parser: https://gist.github.com/maephisto/8433217 > documents added: https://gist.github.com/maephisto/8433719 > I tested it with Solr/Lucene4.6.0 stock example. The plugin was built using > NetBeans. > I used gists inside the ticket in order to keep the description shorter. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-1485) Payload support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994858#comment-15994858 ] Erik Hatcher edited comment on SOLR-1485 at 5/3/17 1:33 PM: At the very least, if you want to do some lowercasing, or other token filtering, one could do that either before or after DelimitedPayloadTokenFilter, and the current implementation will at least match exact'ish phrases and payload score or check them - so it's actually not a bad first pass. (At first I implemented it with simple space splitting, as *_dps/*_dpf/*_dpi do, but then added analysis to add more configurability). was (Author: ehatcher): At the very least, if you want to do some lowercasing, or other token filtering, one could do that either before or after DelimitedPayloadTokenFilter, and the current implementation will at least match exact'ish phrases and payload score or check them - so it's actually not a bad first pass. (At first I implemented it with simple space splitting, as DPTF does, but then added analysis). > Payload support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-1485) Payload support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994858#comment-15994858 ] Erik Hatcher edited comment on SOLR-1485 at 5/3/17 1:34 PM: At the very least, if you want to do some lowercasing, or other token filtering, one could do that either before or after DelimitedPayloadTokenFilter, and the current implementation will at least match exact'ish phrases and payload score or check them - so it's actually not a bad first pass. (At first I implemented it with simple space splitting, as \*_dps/\*_dpf/\*_dpi do, but then added analysis to add more configurability). was (Author: ehatcher): At the very least, if you want to do some lowercasing, or other token filtering, one could do that either before or after DelimitedPayloadTokenFilter, and the current implementation will at least match exact'ish phrases and payload score or check them - so it's actually not a bad first pass. (At first I implemented it with simple space splitting, as *_dps/*_dpf/*_dpi do, but then added analysis to add more configurability). > Payload support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) Payload support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994858#comment-15994858 ] Erik Hatcher commented on SOLR-1485: At the very least, if you want to do some lowercasing, or other token filtering, one could do that either before or after DelimitedPayloadTokenFilter, and the current implementation will at least match exact'ish phrases and payload score or check them - so it's actually not a bad first pass. (At first I implemented it with simple space splitting, as DPTF does, but then added analysis). > Payload support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10600) Make numTerms=0 the default for /admin/luke
Erik Hatcher created SOLR-10600: --- Summary: Make numTerms=0 the default for /admin/luke Key: SOLR-10600 URL: https://issues.apache.org/jira/browse/SOLR-10600 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Erik Hatcher Fix For: master (7.0) Raise your hand if `/admin/luke` has not been so cool handed? Still searching over here boss. Me too. For 7.0 let's make numTerms=0 the default so it performs well until you ask it not to. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) Payload support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993969#comment-15993969
]
Erik Hatcher commented on SOLR-1485:
[~dsmiley] thanks again for your review - much appreciated.
* Query parsing - yeah, that was a tricky one and I opted for the simplest
thing that made sense given the available payloading of terms will be done by
way of DelimitedPayloadTokenFilter, so rather than trying phrase, boolean, and
other things just delegate to the analyzer and build a SpanTermQuery or
SpanNearQuery with zero slop and ordered. I just documented this on the cwiki
as well as a new upcoming commit that will add it to
PayloadUtils.createSpanQuery(). On the parsing decision I looked around to
find a way to create a SpanQuery conveniently (both PayloadScoreQuery and
SpanPayloadCheckQuery require a *SpanQuery*, not just a Query).
QueryBuilder.createSpanQuery() seemed the ticket, but alas it isn't public and
also suffers from the troubles with TokenStream API hurdles that you mention -
so I adapted it with the fixes that you spotted.
* Thanks for the try-with-resources suggestion - implemented it locally (and
running tests/precommit!) now but will commit that shortly.
* Back to query parsing - I'm definitely open to anything that will work, but
again a SpanQuery is the main constraint here. I don't quite see how subQuery
parsing could be used here. Any suggestions/improvements along these lines are
more than welcome. (my primary use case has been the {{payload()}} function so
the query parsing beyond the quite useful as-is SpanTermQuery wasn't a big
thrust)
> Payload support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch,
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-1485) Payload support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher resolved SOLR-1485.
Resolution: Fixed
long time coming, thanks for the encouragement and patience. finally, payload
support in Solr on the query/function side of things. This includes three
pieces:
* {{payload()}} value source function
* {{payload_score}} query parser
* {{payload_check}} query parser
Docs for these have been added to the cwiki.
> Payload support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch,
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1485) Payload support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-1485: --- Summary: Payload support (was: Payload scoring support) > Payload support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10588) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection failure caused by concurrent core reload.
[ https://issues.apache.org/jira/browse/SOLR-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15992987#comment-15992987 ] Erik Hatcher commented on SOLR-10588: - Looks good, [~mkhludnev]. Cosmetic, but since you asked and I looked at the patch here, I'd remove the space "progress" and the period in the info log. > SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection failure caused > by concurrent core reload. > > > Key: SOLR-10588 > URL: https://issues.apache.org/jira/browse/SOLR-10588 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev > Attachments: consoleFull.html.zip, SOLR-10588.patch, SOLR-10588.patch > > > https://builds.apache.org/job/Lucene-Solr-Tests-master/1788/testReport/junit/junit.framework/TestSuite/org_apache_solr_cloud_SolrCloudExampleTest/ > this NPE, even it might be quite reasonable itself, breaks core reload, and > applying config param. I'm -not- sure, -how- it -'s related- causes to these > constant failures. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10588) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection failure caused by concurrent core reload.
[ https://issues.apache.org/jira/browse/SOLR-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15992912#comment-15992912 ] Erik Hatcher commented on SOLR-10588: - bq. Got 36 failures from Payload/Similarity Sorry Mikhail! My bad, sorry for the hassle that delayed you here. > SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection failure caused > by concurrent core reload. > > > Key: SOLR-10588 > URL: https://issues.apache.org/jira/browse/SOLR-10588 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev > Attachments: consoleFull.html.zip, SOLR-10588.patch, SOLR-10588.patch > > > https://builds.apache.org/job/Lucene-Solr-Tests-master/1788/testReport/junit/junit.framework/TestSuite/org_apache_solr_cloud_SolrCloudExampleTest/ > this NPE, even it might be quite reasonable itself, breaks core reload, and > applying config param. I'm -not- sure, -how- it -'s related- causes to these > constant failures. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) Payload scoring support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15992019#comment-15992019 ] Erik Hatcher commented on SOLR-1485: Leaving this ticket open until the documentation is done, but otherwise, whew, DONE! > Payload scoring support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) Payload scoring support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15992018#comment-15992018 ] Erik Hatcher commented on SOLR-1485: I'm not seeing the git message here, but I've committed to branch_6x now too, including a minor tweak to the similarity wrapper due to API change on master. https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/branch_6x > Payload scoring support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) Payload scoring support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990541#comment-15990541 ] Erik Hatcher commented on SOLR-1485: I've completed both query parsers as well on the jira/SOLR-1485 branch. Any review takers before I merge this over master and then to 6.x? [~dsmiley]? [~erickerickson]? I wonder if there'll be any API issues between master and 6x? > Payload scoring support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) Payload scoring support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990103#comment-15990103 ] Erik Hatcher commented on SOLR-1485: I've now committed/pushed everything to the branch needed for the payload() function, including the dynamic field types for delimited payloading of terms. I think we could call this JIRA satisfied with what's committed so far, however I've got these pieces in addition locally: PayloadCheckQParserPlugin, PayloadScoreQParserPlugin.java, PayloadScoringSimilarityWrapper.java, and an improvement to xmlparser's - may include these along with this issue, not sure yet. > Payload scoring support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) Payload scoring support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990095#comment-15990095 ] Erik Hatcher commented on SOLR-1485: I've started committing to branch jira/SOLR-1485: https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/SOLR-1485 where I've just committed the payload() function (and tests and helper utilities) > Payload scoring support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7041) Remove defaultSearchField and solrQueryParser from schema
[
https://issues.apache.org/jira/browse/SOLR-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-7041:
---
Summary: Remove defaultSearchField and solrQueryParser from schema (was:
Nuke defaultSearchField and solrQueryParser from schema)
> Remove defaultSearchField and solrQueryParser from schema
> -
>
> Key: SOLR-7041
> URL: https://issues.apache.org/jira/browse/SOLR-7041
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0
>
> Attachments: SOLR-7041-defaultOperator.patch, SOLR-7041.patch
>
>
> The two tags {{}} and {{solrQueryParser}} were deprecated
> in Solr3.6 (SOLR-2724). Time to nuke them from code and {{schema.xml}} in 5.0?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7808) PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods
[ https://issues.apache.org/jira/browse/LUCENE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved LUCENE-7808. -- Resolution: Fixed > PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods > - > > Key: LUCENE-7808 > URL: https://issues.apache.org/jira/browse/LUCENE-7808 > Project: Lucene - Core > Issue Type: Bug >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: master (7.0), 6.6 > > Attachments: LUCENE-7808.patch, LUCENE-7808.patch, LUCENE-7808.patch > > > Both PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods, causing caching issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7481) SpanPayloadCheckQuery and PayloadScoreQuery are missing rewrite methods
[
https://issues.apache.org/jira/browse/LUCENE-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher resolved LUCENE-7481.
--
Resolution: Fixed
whew! (apologies for the multiple commits, just getting familiar with how to
local branch and -not- squash merge - lesson learned)
> SpanPayloadCheckQuery and PayloadScoreQuery are missing rewrite methods
> ---
>
> Key: LUCENE-7481
> URL: https://issues.apache.org/jira/browse/LUCENE-7481
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.x
>Reporter: Roman Chyla
>Assignee: Erik Hatcher
> Fix For: master (7.0), 6.6
>
>
> If used with a wildcard query, the result is a failure saying: "Rewrite query
> first"
> The SpanNearQuery has the rewrite method; however the SpanPayloadCheckQuery
> just returns the query itself.
> this works:
> ```
> spanNear([vectrfield:ebyuugz, SpanMultiTermQueryWrapper(vectrfield:e*),
> SpanMultiTermQueryWrapper(vectrfield:m*),
> SpanMultiTermQueryWrapper(vectrfield:f*)], 0, true)
> ```
> code to generate the query:
> ```
> private Query getSpanQuery(String[] parts, int howMany, boolean truncate)
> throws UnsupportedEncodingException {
> SpanQuery[] clauses = new SpanQuery[howMany+1];
> clauses[0] = new SpanTermQuery(new Term("vectrfield",
> parts[0])); // surname
> for (int i = 0; i < howMany; i++) {
> if (truncate) {
> SpanMultiTermQueryWrapper q = new
> SpanMultiTermQueryWrapper(new WildcardQuery(new
> Term("vectrfield", parts[i+1].substring(0, 1) + "*")));
> clauses[i+1] = q;
> }
> else {
> clauses[i+1] = new SpanTermQuery(new
> Term("vectrfield", parts[i+1]));
> }
> }
> SpanNearQuery sq = new SpanNearQuery(clauses, 0, true); //
> match in order
> return sq;
> }
> ```
> and this fails:
> ```
> spanPayCheck(spanNear([vectrfield:ebyuugz,
> SpanMultiTermQueryWrapper(vectrfield:e*),
> SpanMultiTermQueryWrapper(vectrfield:m*),
> SpanMultiTermQueryWrapper(vectrfield:f*)], 1, true), payloadRef: 0;1;2;3;)
> ```
> each clause is made of:
> ```
> new SpanMultiTermQueryWrapper(new WildcardQuery(new
> Term("vectrfield", parts[i+1].substring(0, 1) + "*")));
> ```
> It is a regression; the code was working well in SOLR4.x
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7808) PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods
[ https://issues.apache.org/jira/browse/LUCENE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated LUCENE-7808: - Attachment: LUCENE-7808.patch this patch adds the rewrite to PayloadScoreQuery too, along with test. ready to commit to cover this JIRA and LUCENE-7481 > PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods > - > > Key: LUCENE-7808 > URL: https://issues.apache.org/jira/browse/LUCENE-7808 > Project: Lucene - Core > Issue Type: Bug >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: master (7.0), 6.6 > > Attachments: LUCENE-7808.patch, LUCENE-7808.patch, LUCENE-7808.patch > > > Both PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods, causing caching issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7481) SpanPayloadCheckQuery and PayloadScoreQuery are missing rewrite methods
[
https://issues.apache.org/jira/browse/LUCENE-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated LUCENE-7481:
-
Summary: SpanPayloadCheckQuery and PayloadScoreQuery are missing rewrite
methods (was: SpanPayloadCheckQuery is missing rewrite method)
> SpanPayloadCheckQuery and PayloadScoreQuery are missing rewrite methods
> ---
>
> Key: LUCENE-7481
> URL: https://issues.apache.org/jira/browse/LUCENE-7481
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.x
>Reporter: Roman Chyla
>Assignee: Erik Hatcher
> Fix For: master (7.0), 6.6
>
>
> If used with a wildcard query, the result is a failure saying: "Rewrite query
> first"
> The SpanNearQuery has the rewrite method; however the SpanPayloadCheckQuery
> just returns the query itself.
> this works:
> ```
> spanNear([vectrfield:ebyuugz, SpanMultiTermQueryWrapper(vectrfield:e*),
> SpanMultiTermQueryWrapper(vectrfield:m*),
> SpanMultiTermQueryWrapper(vectrfield:f*)], 0, true)
> ```
> code to generate the query:
> ```
> private Query getSpanQuery(String[] parts, int howMany, boolean truncate)
> throws UnsupportedEncodingException {
> SpanQuery[] clauses = new SpanQuery[howMany+1];
> clauses[0] = new SpanTermQuery(new Term("vectrfield",
> parts[0])); // surname
> for (int i = 0; i < howMany; i++) {
> if (truncate) {
> SpanMultiTermQueryWrapper q = new
> SpanMultiTermQueryWrapper(new WildcardQuery(new
> Term("vectrfield", parts[i+1].substring(0, 1) + "*")));
> clauses[i+1] = q;
> }
> else {
> clauses[i+1] = new SpanTermQuery(new
> Term("vectrfield", parts[i+1]));
> }
> }
> SpanNearQuery sq = new SpanNearQuery(clauses, 0, true); //
> match in order
> return sq;
> }
> ```
> and this fails:
> ```
> spanPayCheck(spanNear([vectrfield:ebyuugz,
> SpanMultiTermQueryWrapper(vectrfield:e*),
> SpanMultiTermQueryWrapper(vectrfield:m*),
> SpanMultiTermQueryWrapper(vectrfield:f*)], 1, true), payloadRef: 0;1;2;3;)
> ```
> each clause is made of:
> ```
> new SpanMultiTermQueryWrapper(new WildcardQuery(new
> Term("vectrfield", parts[i+1].substring(0, 1) + "*")));
> ```
> It is a regression; the code was working well in SOLR4.x
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7481) SpanPayloadCheckQuery is missing rewrite method
[
https://issues.apache.org/jira/browse/LUCENE-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated LUCENE-7481:
-
Fix Version/s: 6.6
master (7.0)
> SpanPayloadCheckQuery is missing rewrite method
> ---
>
> Key: LUCENE-7481
> URL: https://issues.apache.org/jira/browse/LUCENE-7481
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.x
>Reporter: Roman Chyla
>Assignee: Erik Hatcher
> Fix For: master (7.0), 6.6
>
>
> If used with a wildcard query, the result is a failure saying: "Rewrite query
> first"
> The SpanNearQuery has the rewrite method; however the SpanPayloadCheckQuery
> just returns the query itself.
> this works:
> ```
> spanNear([vectrfield:ebyuugz, SpanMultiTermQueryWrapper(vectrfield:e*),
> SpanMultiTermQueryWrapper(vectrfield:m*),
> SpanMultiTermQueryWrapper(vectrfield:f*)], 0, true)
> ```
> code to generate the query:
> ```
> private Query getSpanQuery(String[] parts, int howMany, boolean truncate)
> throws UnsupportedEncodingException {
> SpanQuery[] clauses = new SpanQuery[howMany+1];
> clauses[0] = new SpanTermQuery(new Term("vectrfield",
> parts[0])); // surname
> for (int i = 0; i < howMany; i++) {
> if (truncate) {
> SpanMultiTermQueryWrapper q = new
> SpanMultiTermQueryWrapper(new WildcardQuery(new
> Term("vectrfield", parts[i+1].substring(0, 1) + "*")));
> clauses[i+1] = q;
> }
> else {
> clauses[i+1] = new SpanTermQuery(new
> Term("vectrfield", parts[i+1]));
> }
> }
> SpanNearQuery sq = new SpanNearQuery(clauses, 0, true); //
> match in order
> return sq;
> }
> ```
> and this fails:
> ```
> spanPayCheck(spanNear([vectrfield:ebyuugz,
> SpanMultiTermQueryWrapper(vectrfield:e*),
> SpanMultiTermQueryWrapper(vectrfield:m*),
> SpanMultiTermQueryWrapper(vectrfield:f*)], 1, true), payloadRef: 0;1;2;3;)
> ```
> each clause is made of:
> ```
> new SpanMultiTermQueryWrapper(new WildcardQuery(new
> Term("vectrfield", parts[i+1].substring(0, 1) + "*")));
> ```
> It is a regression; the code was working well in SOLR4.x
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-7481) SpanPayloadCheckQuery is missing rewrite method
[
https://issues.apache.org/jira/browse/LUCENE-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher reassigned LUCENE-7481:
Assignee: Erik Hatcher
> SpanPayloadCheckQuery is missing rewrite method
> ---
>
> Key: LUCENE-7481
> URL: https://issues.apache.org/jira/browse/LUCENE-7481
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.x
>Reporter: Roman Chyla
>Assignee: Erik Hatcher
> Fix For: master (7.0), 6.6
>
>
> If used with a wildcard query, the result is a failure saying: "Rewrite query
> first"
> The SpanNearQuery has the rewrite method; however the SpanPayloadCheckQuery
> just returns the query itself.
> this works:
> ```
> spanNear([vectrfield:ebyuugz, SpanMultiTermQueryWrapper(vectrfield:e*),
> SpanMultiTermQueryWrapper(vectrfield:m*),
> SpanMultiTermQueryWrapper(vectrfield:f*)], 0, true)
> ```
> code to generate the query:
> ```
> private Query getSpanQuery(String[] parts, int howMany, boolean truncate)
> throws UnsupportedEncodingException {
> SpanQuery[] clauses = new SpanQuery[howMany+1];
> clauses[0] = new SpanTermQuery(new Term("vectrfield",
> parts[0])); // surname
> for (int i = 0; i < howMany; i++) {
> if (truncate) {
> SpanMultiTermQueryWrapper q = new
> SpanMultiTermQueryWrapper(new WildcardQuery(new
> Term("vectrfield", parts[i+1].substring(0, 1) + "*")));
> clauses[i+1] = q;
> }
> else {
> clauses[i+1] = new SpanTermQuery(new
> Term("vectrfield", parts[i+1]));
> }
> }
> SpanNearQuery sq = new SpanNearQuery(clauses, 0, true); //
> match in order
> return sq;
> }
> ```
> and this fails:
> ```
> spanPayCheck(spanNear([vectrfield:ebyuugz,
> SpanMultiTermQueryWrapper(vectrfield:e*),
> SpanMultiTermQueryWrapper(vectrfield:m*),
> SpanMultiTermQueryWrapper(vectrfield:f*)], 1, true), payloadRef: 0;1;2;3;)
> ```
> each clause is made of:
> ```
> new SpanMultiTermQueryWrapper(new WildcardQuery(new
> Term("vectrfield", parts[i+1].substring(0, 1) + "*")));
> ```
> It is a regression; the code was working well in SOLR4.x
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7808) PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods
[ https://issues.apache.org/jira/browse/LUCENE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15986562#comment-15986562 ] Erik Hatcher commented on LUCENE-7808: -- [~romseygeek] - I fumbled for a moment, but think I understand the rewrite issue and have made a test and fix in my latest patch. I imagine that PayloadScoreQuery needs the same treatment, so I'll tackle that as well here. > PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods > - > > Key: LUCENE-7808 > URL: https://issues.apache.org/jira/browse/LUCENE-7808 > Project: Lucene - Core > Issue Type: Bug >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: master (7.0), 6.6 > > Attachments: LUCENE-7808.patch, LUCENE-7808.patch > > > Both PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods, causing caching issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7808) PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods
[ https://issues.apache.org/jira/browse/LUCENE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated LUCENE-7808: - Attachment: LUCENE-7808.patch fix for SpanPayloadCheckQuery's rewrite+test - solves LUCENE-7481 > PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods > - > > Key: LUCENE-7808 > URL: https://issues.apache.org/jira/browse/LUCENE-7808 > Project: Lucene - Core > Issue Type: Bug >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: master (7.0), 6.6 > > Attachments: LUCENE-7808.patch, LUCENE-7808.patch > > > Both PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods, causing caching issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7808) PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods
[
https://issues.apache.org/jira/browse/LUCENE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15986521#comment-15986521
]
Erik Hatcher commented on LUCENE-7808:
--
[~romseygeek] - I think I'm getting warmer. I implemented this (currently
failing) test:
{code}
public void testRewrite() throws IOException {
SpanMultiTermQueryWrapper fou = new SpanMultiTermQueryWrapper(new
WildcardQuery(new Term("field", "fou*")));
SpanMultiTermQueryWrapper fiv = new SpanMultiTermQueryWrapper(new
WildcardQuery(new Term("field", "fiv*")));
SpanNearQuery sq = new SpanNearQuery(new SpanQuery[] {fou, fiv}, 0, true);
List payloads = new ArrayList<>();
payloads.add(new BytesRef("pos: 0"));
BytesRef payload2 = new BytesRef("pos: 1");
SpanPayloadCheckQuery query = new SpanPayloadCheckQuery(sq, payloads);
checkHits(query, new int[]{1});
}
{code}
The above errors with "java.lang.IllegalArgumentException: Rewrite first!".
> PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and
> .hashCode methods
> -
>
> Key: LUCENE-7808
> URL: https://issues.apache.org/jira/browse/LUCENE-7808
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: master (7.0), 6.6
>
> Attachments: LUCENE-7808.patch
>
>
> Both PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and
> .hashCode methods, causing caching issues.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7808) PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods
[ https://issues.apache.org/jira/browse/LUCENE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15986449#comment-15986449 ] Erik Hatcher commented on LUCENE-7808: -- [~romseygeek] thanks for feedback. I did use Objects.hash() in the .hashCode's that I worked on - is that not quite correct? As for rewrite() - I'm not sure what is needed there exactly. For some reason I added a .rewrite to SpanPayloadCheckQuery, but not to PayloadScoreQuery - but I guess I didn't do that fully? Do you have an example or some other hints as to how to implement what is needed? Happy to do the work while I'm in there! > PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods > - > > Key: LUCENE-7808 > URL: https://issues.apache.org/jira/browse/LUCENE-7808 > Project: Lucene - Core > Issue Type: Bug >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: master (7.0), 6.6 > > Attachments: LUCENE-7808.patch > > > Both PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods, causing caching issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7808) PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods
[ https://issues.apache.org/jira/browse/LUCENE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated LUCENE-7808: - Attachment: LUCENE-7808.patch (initially failing) tests and implementation fixes > PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods > - > > Key: LUCENE-7808 > URL: https://issues.apache.org/jira/browse/LUCENE-7808 > Project: Lucene - Core > Issue Type: Bug >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: master (7.0), 6.6 > > Attachments: LUCENE-7808.patch > > > Both PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and > .hashCode methods, causing caching issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7808) PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods
Erik Hatcher created LUCENE-7808: Summary: PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods Key: LUCENE-7808 URL: https://issues.apache.org/jira/browse/LUCENE-7808 Project: Lucene - Core Issue Type: Bug Reporter: Erik Hatcher Assignee: Erik Hatcher Fix For: master (7.0), 6.6 Both PayloadScoreQuery and SpanPayloadCheckQuery have incomplete .equals and .hashCode methods, causing caching issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1485) Payload scoring support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-1485: --- Fix Version/s: 6.6 > Payload scoring support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.6, master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9596) stopped working in Solr 6.2
[ https://issues.apache.org/jira/browse/SOLR-9596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15981371#comment-15981371 ] Erik Hatcher commented on SOLR-9596: +1 - I've used this patch within my SOLR-1485 work to get some introspection to document the payload feature. Let's commit. > stopped working in > Solr 6.2 > --- > > Key: SOLR-9596 > URL: https://issues.apache.org/jira/browse/SOLR-9596 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Priority: Minor > Attachments: SOLR-9596.patch > > > As a result of changes introduced in Lucene 6.2 by LUCENE-7323, > SimpleTextCodec's postings and doc values formats can only be used from > SimpleTextCodec. That means that Solr's default codecFactory > SchemaCodecFactory, which enables per-field specification of postings and doc > values formats by extending LuceneXXCodec to pull per-field specification > from the schema, can't be used with SimpleText postings and doc values > formats. > What Solr could instead do is provide a non-schema-aware > SimpleTextCodecFactory. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-1485) Payload scoring support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977930#comment-15977930
]
Erik Hatcher edited comment on SOLR-1485 at 4/21/17 12:21 PM:
--
It's interesting to note that there is actually one query built in that could
handle payload scoring already: {{q=\{!xmlparser}weighted}}, with hardcoded
"average" function and includeSpanScore=true, resulting in the above data
example an output of:
{code}
id,score
2,71.00154
{code}
And here's a patch that adds includeSpanScore control flexibility to
{{}}:
{code}
---
a/lucene/queryparser/src/java/org/apache/lucene/queryparser/xml/builders/BoostingTermBuilder.java
+++
b/lucene/queryparser/src/java/org/apache/lucene/queryparser/xml/builders/BoostingTermBuilder.java
@@ -34,11 +34,12 @@ public class BoostingTermBuilder extends SpanBuilderBase {
@Override
public SpanQuery getSpanQuery(Element e) throws ParserException {
String fieldName = DOMUtils.getAttributeWithInheritanceOrFail(e,
"fieldName");
+boolean includeSpanQuery = DOMUtils.getAttribute(e, "includeSpanScore",
true);
String value = DOMUtils.getNonBlankTextOrFail(e);
-// TODO: add parameter to control PayloadScoreQuery's `includeSpanScore`
and `PayloadFunction`
+// TODO: add parameter to control PayloadScoreQuery's and `PayloadFunction`
SpanQuery btq = new PayloadScoreQuery(new SpanTermQuery(new
Term(fieldName, value)),
-new AveragePayloadFunction());
+new AveragePayloadFunction(), includeSpanQuery);
btq = new SpanBoostQuery(btq, DOMUtils.getAttribute(e, "boost", 1.0f));
return btq;
}
{code}
was (Author: ehatcher):
It's interesting to note that there is actually one query built in that could
handle payload scoring already: {{q=\{!xmlparser}weighted}}, with hardcoded
"average" function and includeSpanScore=true, resulting in the above data
example an output of:
{code}
id,score
2,71.00154
{code}
> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch,
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-1485) Payload scoring support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977923#comment-15977923
]
Erik Hatcher edited comment on SOLR-1485 at 4/21/17 12:07 PM:
--
With the latest patch, one can index payloaded terms like this:
{code}
bin/solr create -c payloads
bin/post -c payloads -type text/csv -out yes -d
$'id,weighted_terms_dpf\n1,one|1.0 two|2.0 three|3.0\n2,weighted|50.0
weighted|100.0'
# this is two documents:
# 1: one|1.0 two|2.0 three|3.0
# 2: weighted|50.0 weighted|100.0
{code}
and then get the values back as scores like this:
{code}
http://localhost:8983/solr/payloads/select?q={!payload_score
f=weighted_terms_dpf v=$payload_term
func=max}=id,*_dpf,score=csv_term=two
* _term=two
id,score
1,2.0
* _term=three:
id,score
1,3.0
* _term=weighted (func=max):
id,score
2,100.0
* _term=weighted (func=min):
id,score
2,50.0
* _term=weighted (func=average):
id,score
2,75.0
{code}
was (Author: ehatcher):
With the latest patch, one can index payloaded terms like this:
{code}
bin/solr create -c payloads
bin/post -c payloads -type text/csv -out yes -d
$'id,weighted_terms_dpf\n1,one|1.0 two|2.0 three|3.0\n2,weighted|50.0
weighted|100.0'
{code}
and then get the values back as scores like this:
{code}
http://localhost:8983/solr/payloads/select?q={!payload_score
f=weighted_terms_dpf v=$payload_term
func=max}=id,*_dpf,score=csv_term=two
* _term=two
id,score
1,2.0
* _term=three:
id,score
1,3.0
* _term=weighted (func=max):
id,score
2,100.0
* _term=weighted (func=min):
id,score
2,50.0
* _term=weighted (func=average):
id,score
2,75.0
{code}
> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch,
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-1485) Payload scoring support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977930#comment-15977930
]
Erik Hatcher edited comment on SOLR-1485 at 4/21/17 1:50 AM:
-
It's interesting to note that there is actually one query built in that could
handle payload scoring already: {{q=\{!xmlparser}weighted}}, with hardcoded
"average" function and includeSpanScore=true, resulting in the above data
example an output of:
{code}
id,score
2,71.00154
{code}
was (Author: ehatcher):
It's interested to note that there is actually one query built in that could
handle payload scoring already: {{q=\{!xmlparser}weighted}}, with hardcoded
"average" function and includeSpanScore=true, resulting in the above data
example an output of:
{code}
id,score
2,71.00154
{code}
> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch,
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) Payload scoring support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977930#comment-15977930
]
Erik Hatcher commented on SOLR-1485:
It's interested to note that there is actually one query built in that could
handle payload scoring already: {{q=\{!xmlparser}weighted}}, with hardcoded
"average" function and includeSpanScore=true, resulting in the above data
example an output of:
{code}
id,score
2,71.00154
{code}
> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch,
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) Payload scoring support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977923#comment-15977923
]
Erik Hatcher commented on SOLR-1485:
With the latest patch, one can index payloaded terms like this:
{code}
bin/solr create -c payloads
bin/post -c payloads -type text/csv -out yes -d
$'id,weighted_terms_dpf\n1,one|1.0 two|2.0 three|3.0\n2,weighted|50.0
weighted|100.0'
{code}
and then get the values back as scores like this:
{code}
http://localhost:8983/solr/payloads/select?q={!payload_score
f=weighted_terms_dpf v=$payload_term
func=max}=id,*_dpf,score=csv_term=two
* _term=two
id,score
1,2.0
* _term=three:
id,score
1,3.0
* _term=weighted (func=max):
id,score
2,100.0
* _term=weighted (func=min):
id,score
2,50.0
* _term=weighted (func=average):
id,score
2,75.0
{code}
> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch,
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1485) Payload scoring support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-1485: --- Attachment: SOLR-1485.patch a few fiddly changes, but most relevantly added three dynamic fields/types to the data_driven configuration: *_dpf, *_dpi, and *_dps, for delimited_payloads float, int, and string. > Payload scoring support > --- > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: master (7.0) > > Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, > SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, > SOLR-1485.patch > > > Solr has no support for Lucene's PayloadScoreQuery, yet it has support for > indexing payloads (via DelimitedPayloadTokenFilter or > NumericPayloadTokenFilter). > This issue adds value source and query parser support for leveraging payloads > created by those token filters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-1485) Payload scoring support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973885#comment-15973885
]
Erik Hatcher edited comment on SOLR-1485 at 4/19/17 3:29 PM:
-
While I'm at it, I found that Lucene's {{PayloadScoreQuery}} had a
.equals/hashCode/cache bug in that it didn't take into account the
{{includeSpanScore}} flag - fixed here.
was (Author: ehatcher):
While I'm at it, I found that Lucene's {{PayloadScoreQuery}} had a
.equals/hashCode/cache bug in that it didn't into account the includeSpanScore
flag - fixed here.
> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1485) Payload scoring support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-1485:
---
Attachment: SOLR-1485.patch
While I'm at it, I found that Lucene's {{PayloadScoreQuery}} had a
.equals/hashCode/cache bug in that it didn't into account the includeSpanScore
flag - fixed here.
> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1485) Payload scoring support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-1485:
---
Attachment: SOLR-1485.patch
last patch had a recursive loop issue on the SimScorer ({{this}} instead of the
delegate)
> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png,
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for
> indexing payloads (via DelimitedPayloadTokenFilter or
> NumericPayloadTokenFilter).
> This issue adds value source and query parser support for leveraging payloads
> created by those token filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
