[jira] [Created] (SOLR-9795) Jetty 9.2.19 upgrade
Bill Bell created SOLR-9795: --- Summary: Jetty 9.2.19 upgrade Key: SOLR-9795 URL: https://issues.apache.org/jira/browse/SOLR-9795 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Bill Bell Upgrade Jetty to 9.2.19 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9771) Resolv Variables in DIH when using encryptKeyFile.
Bill Bell created SOLR-9771:
---
Summary: Resolv Variables in DIH when using encryptKeyFile.
Key: SOLR-9771
URL: https://issues.apache.org/jira/browse/SOLR-9771
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 5.5.3
Reporter: Bill Bell
I would like to use a variable like ${db.passwdkey} for password when using
encryptKeyFile in various DIH files.
-Ddb.passwdkey="U2FsdGVkX18QMjY0yfCqlfBMvAB4d3XkwY96L7gfO2o="
Please backport to 5.5.3
This does not appear to work when used in DIH below.
password="U2FsdGVkX18QMjY0yfCqlfBMvAB4d3XkwY96L7gfO2o="
encryptKeyFile="/location/of/encryptionkey"
/>
{{{
password=${solr.passkey}
encryptKeyFile="/location/of/encryptionkey"
}}}
/>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8986) Windows solr.cmd seems to require -p 8983
[ https://issues.apache.org/jira/browse/SOLR-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333204#comment-15333204 ] Bill Bell commented on SOLR-8986: - I was getting this issue on 5.4.1... > Windows solr.cmd seems to require -p 8983 > - > > Key: SOLR-8986 > URL: https://issues.apache.org/jira/browse/SOLR-8986 > Project: Solr > Issue Type: Bug > Reporter: Bill Bell > Attachments: start-solr-on-windows.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9213) Join does not work on multiValued fields / single field
Bill Bell created SOLR-9213:
---
Summary: Join does not work on multiValued fields / single field
Key: SOLR-9213
URL: https://issues.apache.org/jira/browse/SOLR-9213
Project: Solr
Issue Type: Bug
Affects Versions: 5.4.1
Reporter: Bill Bell
> I have having issues with {!join}. If the core have multiValued field and
> the inner join does not have a multiValued field it does not find the
> ones...
>
> Solr 5.3.1... 5.3.1
>
> Example.
>
> PS1226 is in practicing_specialties_codes in providersearch core. This
> field is multiValued.
>
> in the autosuggest core there is NOT a field for PS1226 in there. This
> field is called prac_spec_code and is single values.
>
>
>
> http://localhost:8983/solr/providersearch/select?q=*%3A*&wt=json&indent=true&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes
>
> I get:
>
>
>- docs:
>[
> -
> {
> - practicing_specialties_codes:
> [
> - "PS1010",
> - "PS282",
> - "PS1226"
> ]
> }
> ]
>
>
>
> In autosuggest there is nothing:
>
>
> http://localhost:8983/solr/autosuggest/select?q=*%3A*&wt=json&indent=true&fq=prac_spec_code:PS1226&fl=prac_spec_code
>
> Nothing.
>
> Then a join should find what is in providersearch but missing in
> autosuggest.
>
>
> http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
> <http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes&fq=NOT%20%7B!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest%7Dauto_type:PRACSPEC>
>
> or
>
>
> http://hgsolr2sl1:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
> <http://hgsolr2sl1:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20%7B!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest%7Dauto_type:PRACSPEC>
>
> or
>
>
> http://hgsolr2sl1:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}*:*
> <http://hgsolr2sl1:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20%7B!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest%7D*:*>
>
> I also tried *:* AND NOT {!join}
>
> I get 0 results. This seems to be a bug.
>
> {
>
>- responseHeader:
>{
> - status: 0,
> - QTime: 178,
> - params:
> {
> - q: "*:*",
> - fl: "practicing_specialties_codes",
> - fq: "NOT {!join from=prac_spec_code
> to=practicing_specialties_codes fromIndex=autosuggest}*:*",
> - rows: "10",
> - wt: "json",
> - debugQuery: "true"
> }
> },
>- response:
>{
> - numFound: 0,
> - start: 0,
> - docs: [ ]
> },
>- debug:
>{
> - rawquerystring: "*:*",
> - querystring: "*:*",
> - parsedquery: "MatchAllDocsQuery(*:*)",
> - parsedquery_toString: "*:*",
> - explain: { },
> - QParser: "LuceneQParser",
> - filter_queries:
> [
> - "NOT {!join from=prac_spec_code
> to=practicing_specialties_codes fromIndex=autosuggest}*:*"
> ],
> - parsed_filter_queries:
> [
> - "-JoinQuery({!join from=prac_spec_code
> to=practicing_specialties_codes fromIndex=autosuggest}*:*)"
> ],
> - timing:
> {
> - time: 177,
> - prepare:
> {
> - time: 0,
> - query:
> {
>- time: 0
>},
[jira] [Created] (SOLR-9145) Support Jetty 9.3.9.v20160517
Bill Bell created SOLR-9145: --- Summary: Support Jetty 9.3.9.v20160517 Key: SOLR-9145 URL: https://issues.apache.org/jira/browse/SOLR-9145 Project: Solr Issue Type: Bug Reporter: Bill Bell Jetty new version is released. Do we support on 5.5 and 6.0 ? 9.3.9.v20160517 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8986) Windows solr.cmd seems to require -p 8983
Bill Bell created SOLR-8986: --- Summary: Windows solr.cmd seems to require -p 8983 Key: SOLR-8986 URL: https://issues.apache.org/jira/browse/SOLR-8986 Project: Solr Issue Type: Bug Reporter: Bill Bell -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8466) Add support for UnInvertedField based faceting to FacetComponent
[ https://issues.apache.org/jira/browse/SOLR-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080530#comment-15080530 ] Bill Bell commented on SOLR-8466: - This looks good, it appears to add facet.method=uif which it the way it was before. Are we ready to commit? > Add support for UnInvertedField based faceting to FacetComponent > > > Key: SOLR-8466 > URL: https://issues.apache.org/jira/browse/SOLR-8466 > Project: Solr > Issue Type: New Feature > Components: Facet Module, faceting >Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1, 5.4 >Reporter: Jamie Johnson > Attachments: patch.diff > > > The new JSON Faceting API supports building an UnInvertedField to do faceting > which would be beneficial to add to Solr FacetComponent. This would provide > additional options to implementors to choose the appropriate method of > faceting for their particular use case. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8478) {!join} does not work when outside is multiValue
[
https://issues.apache.org/jira/browse/SOLR-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15075703#comment-15075703
]
Bill Bell edited comment on SOLR-8478 at 12/31/15 4:21 AM:
---
providersearch core:
and
autosuggest core:
was (Author: billnbell):
and
> {!join} does not work when outside is multiValue
>
>
> Key: SOLR-8478
> URL: https://issues.apache.org/jira/browse/SOLR-8478
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3.1
>Reporter: Bill Bell
>
> I have having issues with {!join}. If the core have multiValued field and the
> inner join does not have a multiValued field it does not find the ones...
> Solr 5.3.1... 5.3.1
> Example.
> PS1226 is in practicing_specialties_codes in providersearch core. This field
> is multiValued.
> in the autosuggest core there is NOT a field for PS1226 in there. This field
> is called prac_spec_code and is single values.
> http://localhost:8983/solr/providersearch/select?q=*%3A*&wt=json&indent=true&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes
> I get:
> docs:
> [
> {
> practicing_specialties_codes:
> [
> "PS1010",
> "PS282",
> "PS1226"
> ]
> }
> ]
> In autosuggest there is nothing:
> http://localhost:8983/solr/autosuggest/select?q=*%3A*&wt=json&indent=true&fq=prac_spec_code:PS1226&fl=prac_spec_code
> Nothing.
> Then a join should find what is in providersearch but missing in autosuggest.
> http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
> or
> http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
> or
> http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}*:*
> I also tried *:* AND NOT {!join}
> I get 0 results. This seems to be a bug when using MultiValued fields with
> join.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8478) {!join} does not work when outside is multiValue
[
https://issues.apache.org/jira/browse/SOLR-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15075703#comment-15075703
]
Bill Bell commented on SOLR-8478:
-
and
> {!join} does not work when outside is multiValue
>
>
> Key: SOLR-8478
> URL: https://issues.apache.org/jira/browse/SOLR-8478
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3.1
>Reporter: Bill Bell
>
> I have having issues with {!join}. If the core have multiValued field and the
> inner join does not have a multiValued field it does not find the ones...
> Solr 5.3.1... 5.3.1
> Example.
> PS1226 is in practicing_specialties_codes in providersearch core. This field
> is multiValued.
> in the autosuggest core there is NOT a field for PS1226 in there. This field
> is called prac_spec_code and is single values.
> http://localhost:8983/solr/providersearch/select?q=*%3A*&wt=json&indent=true&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes
> I get:
> docs:
> [
> {
> practicing_specialties_codes:
> [
> "PS1010",
> "PS282",
> "PS1226"
> ]
> }
> ]
> In autosuggest there is nothing:
> http://localhost:8983/solr/autosuggest/select?q=*%3A*&wt=json&indent=true&fq=prac_spec_code:PS1226&fl=prac_spec_code
> Nothing.
> Then a join should find what is in providersearch but missing in autosuggest.
> http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
> or
> http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
> or
> http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}*:*
> I also tried *:* AND NOT {!join}
> I get 0 results. This seems to be a bug when using MultiValued fields with
> join.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8478) {!join} does not work when outside is multiValue
[
https://issues.apache.org/jira/browse/SOLR-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-8478:
Description:
I have having issues with {!join}. If the core have multiValued field and the
inner join does not have a multiValued field it does not find the ones...
Solr 5.3.1... 5.3.1
Example.
PS1226 is in practicing_specialties_codes in providersearch core. This field is
multiValued.
in the autosuggest core there is NOT a field for PS1226 in there. This field is
called prac_spec_code and is single values.
http://localhost:8983/solr/providersearch/select?q=*%3A*&wt=json&indent=true&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes
I get:
docs:
[
{
practicing_specialties_codes:
[
"PS1010",
"PS282",
"PS1226"
]
}
]
In autosuggest there is nothing:
http://localhost:8983/solr/autosuggest/select?q=*%3A*&wt=json&indent=true&fq=prac_spec_code:PS1226&fl=prac_spec_code
Nothing.
Then a join should find what is in providersearch but missing in autosuggest.
http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
or
http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
or
http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}*:*
I also tried *:* AND NOT {!join}
I get 0 results. This seems to be a bug when using MultiValued fields with join.
was:
I have having issues with {!join}. If the core have multiValued field and the
inner join does not have a multiValued field it does not find the ones...
Solr 5.3.1... 5.3.1
Example.
PS1226 is in practicing_specialties_codes in providersearch core. This field is
multiValued.
in the autosuggest core there is NOT a field for PS1226 in there. This field is
called prac_spec_code and is single values.
http://localhost:8983/solr/providersearch/select?q=*%3A*&wt=json&indent=true&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes
I get:
{{{
docs:
[
{
practicing_specialties_codes:
[
"PS1010",
"PS282",
"PS1226"
]
}
]
}}}
In autosuggest there is nothing:
http://localhost:8983/solr/autosuggest/select?q=*%3A*&wt=json&indent=true&fq=prac_spec_code:PS1226&fl=prac_spec_code
Nothing.
Then a join should find what is in providersearch but missing in autosuggest.
{{{
http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
}}}
or
{{{
http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
}}}
or
{{{
http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}*:*
}}}
I also tried *:* AND NOT {!join}
I get 0 results. This seems to be a bug when using MultiValued fields with join.
> {!join} does not work when outside is multiValue
> ----
>
> Key: SOLR-8478
> URL: https://issues.apache.org/jira/browse/SOLR-8478
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3.1
>Reporter: Bill Bell
>
> I have having issues with {!join}. If the core have multiValued field and the
> inner join does not have a multiValued field it does not find the ones...
> Solr 5.3.1... 5.3.1
> Example.
> PS1226 is in practicing_specialties_codes in providersearch core. This field
> is multiValued.
> in the autosuggest core there is NOT a field for PS1226 in there. This field
> is called prac_spec_code and is single values.
> http://localhost:8983/solr/providersearch/select?q=*%3A*&wt=json&indent=true&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes
> I get:
> docs:
> [
> {
> prac
[jira] [Created] (SOLR-8478) {!join} does not work when outside is multiValue
Bill Bell created SOLR-8478:
---
Summary: {!join} does not work when outside is multiValue
Key: SOLR-8478
URL: https://issues.apache.org/jira/browse/SOLR-8478
Project: Solr
Issue Type: Bug
Affects Versions: 5.3.1
Reporter: Bill Bell
I have having issues with {!join}. If the core have multiValued field and the
inner join does not have a multiValued field it does not find the ones...
Solr 5.3.1... 5.3.1
Example.
PS1226 is in practicing_specialties_codes in providersearch core. This field is
multiValued.
in the autosuggest core there is NOT a field for PS1226 in there. This field is
called prac_spec_code and is single values.
http://localhost:8983/solr/providersearch/select?q=*%3A*&wt=json&indent=true&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes
I get:
{{{
docs:
[
{
practicing_specialties_codes:
[
"PS1010",
"PS282",
"PS1226"
]
}
]
}}}
In autosuggest there is nothing:
http://localhost:8983/solr/autosuggest/select?q=*%3A*&wt=json&indent=true&fq=prac_spec_code:PS1226&fl=prac_spec_code
Nothing.
Then a join should find what is in providersearch but missing in autosuggest.
{{{
http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fq=practicing_specialties_codes:PS1226&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
}}}
or
{{{
http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}auto_type:PRACSPEC
}}}
or
{{{
http://localhost:8983/solr/providersearch/select?debugQuery=true&wt=json&q=*:*&rows=10&fl=practicing_specialties_codes&fq=NOT%20{!join%20from=prac_spec_code%20to=practicing_specialties_codes%20fromIndex=autosuggest}*:*
}}}
I also tried *:* AND NOT {!join}
I get 0 results. This seems to be a bug when using MultiValued fields with join.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8376) Jetty 9.2.14.v20151106 upgrade from 9.2.11
Bill Bell created SOLR-8376: --- Summary: Jetty 9.2.14.v20151106 upgrade from 9.2.11 Key: SOLR-8376 URL: https://issues.apache.org/jira/browse/SOLR-8376 Project: Solr Issue Type: Bug Affects Versions: 5.3.1 Reporter: Bill Bell Fix For: 5.4 Let's upgrade SOLR 5.3.1 to Jetty 9.2.14.v20151106 which was released recently. Release notes: jetty-9.2.14.v20151106 - 06 November 2015 + 428474 Expose batch mode in the Jetty WebSocket API + 471055 Restore legacy/experimental WebSocket extensions (deflate-frame) + 472082 isOpen returns true on CLOSING Connection + 474068 Update WebSocket Extension for permessage-deflate draft-22 + 474319 Reintroduce blocking connect(). + 474321 Allow synchronous address resolution. + 474453 Tiny buffers (under 7 bytes) fail to compress in permessage-deflate + 474454 Backport permessage-deflate from Jetty 9.3.x to 9.2.x + 474936 WebSocketSessions are not always cleaned out from openSessions + 476023 Incorrect trimming of WebSocket close reason + 476049 When using WebSocket Session.close() there should be no status code or reason sent + 477385 Problem in MANIFEST.MF with version 9.2.10 / 9.2.13. + 477817 Fixed memory leak in QueuedThreadPool + 481006 SSL requests intermittently fail with EOFException when SSL renegotiation is disallowed. + 481236 Make ShutdownMonitor java security manager friendly + 481437 Port ConnectHandler connect and context functionality from Jetty 8. jetty-9.2.13.v20150730 - 30 July 2015 + 472859 ConcatServlet may expose protected resources. + 473006 Encode addPath in URLResource + 473243 Delay resource close for async default content + 473266 Better handling of MultiException + 473322 GatherWrite limit handling + 473624 ProxyServlet.Transparent / TransparentDelegate add trailing slash before query when using prefix. + 473832 SslConnection flips back buffers on handshake exception jetty-9.2.12.v20150709 - 09 July 2015 + 469414 Proxied redirects expose upstream server name. + 469936 Remove usages of SpinLock. + 470184 Send the proxy-to-server request more lazily. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-7993: Attachment: SOLR-7993-test.patch Test for [json] > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3, 5.3.1 >Reporter: Bill Bell > Attachments: SOLR-7993-test.patch, SOLR-7993.patch > > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell reopened SOLR-7993: - Reopening to get committed > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3, 5.3.1 >Reporter: Bill Bell > Attachments: SOLR-7993.patch > > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-7993: Affects Version/s: 5.3.1 > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3, 5.3.1 >Reporter: Bill Bell > Attachments: SOLR-7993.patch > > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956208#comment-14956208 ] Bill Bell commented on SOLR-7993: - Ryan - please check into trunk and 5.4 it works...!!! Please don't mark it resolved unless you check in. > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3, 5.3.1 >Reporter: Bill Bell > Attachments: SOLR-7993.patch > > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8096) Major faceting performance regressions
[ https://issues.apache.org/jira/browse/SOLR-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948050#comment-14948050 ] Bill Bell commented on SOLR-8096: - Are we adding it back and adding an option to enable it? > Major faceting performance regressions > -- > > Key: SOLR-8096 > URL: https://issues.apache.org/jira/browse/SOLR-8096 > Project: Solr > Issue Type: Bug >Affects Versions: 5.0, 5.1, 5.2, 5.3, Trunk >Reporter: Yonik Seeley >Priority: Critical > > Use of the highly optimized faceting that Solr had for multi-valued fields > over relatively static indexes was removed as part of LUCENE-5666, causing > severe performance regressions. > Here are some quick benchmarks to gauge the damage, on a 5M document index, > with each field having between 0 and 5 values per document. *Higher numbers > represent worse 5x performance*. > Solr 5.4_dev faceting time as a percent of Solr 4.10.3 faceting time > ||...|| Percent of index being faceted > ||num_unique_values|| 10% || 50% || 90% || > |10 | 351.17% | 1587.08% | 3057.28% | > |100 | 158.10% | 203.61% | 1421.93% | > |1000 | 143.78% | 168.01% | 1325.87% | > |1| 137.98% | 175.31% | 1233.97% | > |10 | 142.98% | 159.42% | 1252.45% | > |100 | 255.15% | 165.17% | 1236.75% | > For example, a field with 1000 unique values in the whole index, faceting > with 5x took 143% of the 4x time, when ~10% of the docs in the index were > faceted. > One user who brought the performance problem to our attention: > http://markmail.org/message/ekmqh4ocbkwxv3we > "faceting is unusable slow since upgrade to 5.3.0" (from 4.10.3) > The disabling of the UnInvertedField algorithm was previously discovered in > SOLR-7190, but we didn't know just how bad the problem was at that time. > edit: removed "secret" adverb by request -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7211) Off-Heap field cache
[ https://issues.apache.org/jira/browse/SOLR-7211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14944475#comment-14944475 ] Bill Bell commented on SOLR-7211: - Are we going forward with this? > Off-Heap field cache > > > Key: SOLR-7211 > URL: https://issues.apache.org/jira/browse/SOLR-7211 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley > > Off-heap field cache implementation will help with GC issues and enable > native code performance optimizations -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell resolved SOLR-7993. - Resolution: Fixed > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3 >Reporter: Bill Bell > Attachments: SOLR-7993.patch > > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14736351#comment-14736351 ] Bill Bell commented on SOLR-7993: - Can we release this in 5.3.1 ? > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3 >Reporter: Bill Bell > Attachments: SOLR-7993.patch > > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14726800#comment-14726800 ] Bill Bell edited comment on SOLR-7993 at 9/2/15 5:55 AM: - To test this prior to the patch: 1. http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&indent=true&fl=provider_json:[json] This returns no fields. 2. http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&indent=true&fl=provider_json:[json],provider_json This returns provider_json in RAW. With the patch: 3. http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&indent=true&fl=provider_json:[json] This returns provider_json in raw json. was (Author: billnbell): To test this: 1. http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&indent=true&fl=provider_json:[json] This returns no fields. 2. http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&indent=true&fl=provider_json:[json],provider_json This returns provider_json in RAW. > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3 >Reporter: Bill Bell > Attachments: SOLR-7993.patch > > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14726800#comment-14726800 ] Bill Bell commented on SOLR-7993: - To test this: 1. http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&indent=true&fl=provider_json:[json] This returns no fields. 2. http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&indent=true&fl=provider_json:[json],provider_json This returns provider_json in RAW. > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug > Affects Versions: 5.3 >Reporter: Bill Bell > Attachments: SOLR-7993.patch > > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8003) *_json:[json] does not match all fields ending in json and apply the Raw
Bill Bell created SOLR-8003:
---
Summary: *_json:[json] does not match all fields ending in json
and apply the Raw
Key: SOLR-8003
URL: https://issues.apache.org/jira/browse/SOLR-8003
Project: Solr
Issue Type: Bug
Reporter: Bill Bell
http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&indent=true&fl=*_json:[json]
All of those fields are JSON, but it does not apply the [json] to all matching
fields.
error: {
msg: "Error parsing fieldname: Expected identifier at pos 0
str='*_json:[json]'",
code: 400
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14726791#comment-14726791 ] Bill Bell commented on SOLR-7993: - Ryan, I can confirm this works!! I tested multiple JSON fields, 1, 2... We should open a new JIRA ticket for another issue... Less pressing. > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3 >Reporter: Bill Bell > Attachments: SOLR-7993.patch > > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723725#comment-14723725 ] Bill Bell edited comment on SOLR-7993 at 8/31/15 5:54 PM: -- Yes it works with *. It also will show the Raw Json if we add it 2 times like below: http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json],provider_json But our code does not add it 2 times... So we need a patch. We need a unit test for that... Can we get a patch ? was (Author: billnbell): Yes! http://hgsolr2devmstr:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json],provider_json Even if I include it 2 times. We need a unit test for that... Can we get a patch ? > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3 >Reporter: Bill Bell > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723725#comment-14723725 ] Bill Bell commented on SOLR-7993: - Yes! http://hgsolr2devmstr:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json],provider_json Even if I include it 2 times. We need a unit test for that... Can we get a patch ? > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3 >Reporter: Bill Bell > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7993) json stopped working on 5.3.0
[
https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723653#comment-14723653
]
Bill Bell commented on SOLR-7993:
-
Info.
{
"responseHeader":{
"status":0,
"QTime":31,
"params":{
"q":"*:*",
"indent":"true",
"fl":"provider_json:[json]",
"wt":"json"}},
"response":{"numFound":2903672,"start":0,"docs":[
{},
{},
{},
{},
{},
{},
{},
{},
{},
{}]
}}
> json stopped working on 5.3.0
> -
>
> Key: SOLR-7993
> URL: https://issues.apache.org/jira/browse/SOLR-7993
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Bill Bell
>
> This stopped working:
> http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json]
> It now does not show the field 5.2.1 worked fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7993) json stopped working on 5.3.0
Bill Bell created SOLR-7993: --- Summary: json stopped working on 5.3.0 Key: SOLR-7993 URL: https://issues.apache.org/jira/browse/SOLR-7993 Project: Solr Issue Type: Bug Affects Versions: 5.3 Reporter: Bill Bell This stopped working: http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7993) json stopped working on 5.3.0
[ https://issues.apache.org/jira/browse/SOLR-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723630#comment-14723630 ] Bill Bell commented on SOLR-7993: - Linked > json stopped working on 5.3.0 > - > > Key: SOLR-7993 > URL: https://issues.apache.org/jira/browse/SOLR-7993 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3 >Reporter: Bill Bell > > This stopped working: > http://localhost:8983/solr/provider/select?q=*%3A*&wt=json&fl=provider_json:[json] > It now does not show the field 5.2.1 worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3
[
https://issues.apache.org/jira/browse/SOLR-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702549#comment-14702549
]
Bill Bell commented on SOLR-7339:
-
Java 7 is EOL
Java SE 7 End of Public Updates Notice
After April 2015, Oracle will no longer post updates of Java SE 7 to its public
download sites. Existing Java SE 7 downloads already posted as of April 2015
will remain accessible in the Java Archive on the Oracle Technology Network.
Developers and end-users are encouraged to update to more recent Java SE
versions that remain available for public download in order to continue
receiving public updates and security enhancements.
https://www.java.com/en/download/faq/java_7.xml
> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
> Issue Type: Improvement
>Reporter: Gregg Donovan
> Attachments: SOLR-7339.patch
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699]
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading
> Jetty. The server configuration would need to change and a new HTTP client
> ([Jetty's own
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2],
> [Square's OkHttp|http://square.github.io/okhttp/],
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need
> to be selected and wired up. Perhaps this is worthy of a branch?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7943) Upgrade Jetty to 9.2.13
Bill Bell created SOLR-7943: --- Summary: Upgrade Jetty to 9.2.13 Key: SOLR-7943 URL: https://issues.apache.org/jira/browse/SOLR-7943 Project: Solr Issue Type: Bug Reporter: Bill Bell Let's patch Jetty to 9.2.13 http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/9.2.13.v20150730/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7846) QTs with $variable does not work with query parameter substitution
[
https://issues.apache.org/jira/browse/SOLR-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651169#comment-14651169
]
Bill Bell commented on SOLR-7846:
-
There is a work around,
PS127
hosp_quality_spec_boost:${pspec:${pspec}}
This works.
> QTs with $variable does not work with query parameter substitution
> --
>
> Key: SOLR-7846
> URL: https://issues.apache.org/jira/browse/SOLR-7846
> Project: Solr
> Issue Type: Bug
> Reporter: Bill Bell
>
> http://yonik.com/solr-query-parameter-substitution/
> This is not working as part of QTs in solrconfig.xml due to XML System
> Property Substitution getting confused in SOLR 5.2.1.
> Cannot load the core, since ${value} is being used for XML parameters for
> system property substitution.
> https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
> Can we support both?
> PS127
> hosp_quality_spec_boost:${pspec}
> This does not work since it thinks it is a System Property.
> We can check System Property and if not defined assume it is in Query, or
> have a new parameter?
> {noformat}
> ${variable} - for System Properties
> ${{variable}} - for Query Parameters?
> {noformat}
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators
[ https://issues.apache.org/jira/browse/SOLR-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651144#comment-14651144 ] Bill Bell commented on SOLR-2649: - This is pretty critical to edismax. If the fix is good, let's get it checked in. ? > MM ignored in edismax queries with operators > > > Key: SOLR-2649 > URL: https://issues.apache.org/jira/browse/SOLR-2649 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Magnus Bergmark >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.9, Trunk > > Attachments: SOLR-2649-with-Qop.patch, SOLR-2649-with-Qop.patch, > SOLR-2649.diff, SOLR-2649.patch > > > Hypothetical scenario: > 1. User searches for "stocks oil gold" with MM set to "50%" > 2. User adds "-stockings" to the query: "stocks oil gold -stockings" > 3. User gets no hits since MM was ignored and all terms where AND-ed > together > The behavior seems to be intentional, although the reason why is never > explained: > // For correct lucene queries, turn off mm processing if there > // were explicit operators (except for AND). > boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; > (lines 232-234 taken from > tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) > This makes edismax unsuitable as an replacement to dismax; mm is one of the > primary features of dismax. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7845) sum should treat NULL as 0
[
https://issues.apache.org/jira/browse/SOLR-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645182#comment-14645182
]
Bill Bell commented on SOLR-7845:
-
OK, it might have to do with query($qq, DEFAULT)
http://localhost:8983/solr/select?q=*:*&fl=pwid,sum(0,query($qq,5.0))&qq={!lucene}pwid:2
This returns no default:
2KSTV
X9F6L
2N8LQ
> sum should treat NULL as 0
> --
>
> Key: SOLR-7845
> URL: https://issues.apache.org/jira/browse/SOLR-7845
> Project: Solr
> Issue Type: Bug
>Reporter: Bill Bell
>
> sum(0,query()) used to treat the NULL values in query as 0. It stopped
> working in SOLR 5.
> Do we want to fix this?
> {noformat}
> http://localhost:8983/solr/select?hqval1=pwid:2&q=*:*&fl=pwid,$y&y=sum(0,query({!lucene%20v=$hqval1}))
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7845) sum should treat NULL as 0
[
https://issues.apache.org/jira/browse/SOLR-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-7845:
Description:
sum(0,query()) used to treat the NULL values in query as 0. It stopped working
in SOLR 5.
Do we want to fix this?
{noformat}
http://localhost:8983/solr/select?hqval1=pwid:2&q=*:*&fl=pwid,$y&y=sum(0,query({!lucene%20v=$hqval1}))
{noformat}
was:
sum(0,query()) used to treat the NULL values in query as 0. It stopped working
in SOLR 5.
Do we want to fix this?
http://localhost:8983/solr/select?hqval1=pwid:2&q=*:*&fl=pwid,$y&y=sum(0,query({!lucene%20v=$hqval1}))
> sum should treat NULL as 0
> --
>
> Key: SOLR-7845
> URL: https://issues.apache.org/jira/browse/SOLR-7845
> Project: Solr
> Issue Type: Bug
>Reporter: Bill Bell
>
> sum(0,query()) used to treat the NULL values in query as 0. It stopped
> working in SOLR 5.
> Do we want to fix this?
> {noformat}
> http://localhost:8983/solr/select?hqval1=pwid:2&q=*:*&fl=pwid,$y&y=sum(0,query({!lucene%20v=$hqval1}))
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7846) QTs with $variable does not work with query parameter substitution
[
https://issues.apache.org/jira/browse/SOLR-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-7846:
Description:
http://yonik.com/solr-query-parameter-substitution/
This is not working as part of QTs in solrconfig.xml due to XML System Property
Substitution getting confused in SOLR 5.2.1.
Cannot load the core, since ${value} is being used for XML parameters for
system property substitution.
https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
Can we support both?
PS127
hosp_quality_spec_boost:${pspec}
This does not work since it thinks it is a System Property.
We can check System Property and if not defined assume it is in Query, or have
a new parameter?
{noformat}
${variable} - for System Properties
${{variable}} - for Query Parameters?
{noformat}
Thoughts?
was:
http://yonik.com/solr-query-parameter-substitution/
This is not working as part of QTs in solrconfig.xml due to XML System Property
Substitution getting confused in SOLR 5.2.1.
Cannot load the core, since ${value} is being used for XML parameters for
system property substitution.
https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
Can we support both?
PS127
hosp_quality_spec_boost:${pspec}
This does not work since it thinks it is a System Property.
We can check System Property and if not defined assume it is in Query, or have
a new parameter?
{noformat}
$ { variable } - for System Properties
$ { { variable } } - for Query Parameters?
{noformat}
Thoughts?
> QTs with $variable does not work with query parameter substitution
> --
>
> Key: SOLR-7846
> URL: https://issues.apache.org/jira/browse/SOLR-7846
> Project: Solr
> Issue Type: Bug
> Reporter: Bill Bell
>
> http://yonik.com/solr-query-parameter-substitution/
> This is not working as part of QTs in solrconfig.xml due to XML System
> Property Substitution getting confused in SOLR 5.2.1.
> Cannot load the core, since ${value} is being used for XML parameters for
> system property substitution.
> https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
> Can we support both?
> PS127
> hosp_quality_spec_boost:${pspec}
> This does not work since it thinks it is a System Property.
> We can check System Property and if not defined assume it is in Query, or
> have a new parameter?
> {noformat}
> ${variable} - for System Properties
> ${{variable}} - for Query Parameters?
> {noformat}
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7846) QTs with $variable does not work with query parameter substitution
[
https://issues.apache.org/jira/browse/SOLR-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-7846:
Description:
http://yonik.com/solr-query-parameter-substitution/
This is not working as part of QTs in solrconfig.xml due to XML System Property
Substitution getting confused in SOLR 5.2.1.
Cannot load the core, since ${value} is being used for XML parameters for
system property substitution.
https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
Can we support both?
PS127
hosp_quality_spec_boost:${pspec}
This does not work since it thinks it is a System Property.
We can check System Property and if not defined assume it is in Query, or have
a new parameter?
{noformat}
$ { variable } - for System Properties
$ { { variable } } - for Query Parameters?
{noformat}
Thoughts?
was:
http://yonik.com/solr-query-parameter-substitution/
This is not working as part of QTs in solrconfig.xml due to XML System Property
Substitution getting confused in SOLR 5.2.1.
Cannot load the core, since ${value} is being used for XML parameters for
system property substitution.
https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
Can we support both?
PS127
hosp_quality_spec_boost:${pspec}
This does not work since it thinks it is a System Property.
We can check System Property and if not defined assume it is in Query, or have
a new parameter?
$ { variable } - for System Properties
$ { { variable } } - for Query Parameters?
Thoughts?
> QTs with $variable does not work with query parameter substitution
> --
>
> Key: SOLR-7846
> URL: https://issues.apache.org/jira/browse/SOLR-7846
> Project: Solr
> Issue Type: Bug
> Reporter: Bill Bell
>
> http://yonik.com/solr-query-parameter-substitution/
> This is not working as part of QTs in solrconfig.xml due to XML System
> Property Substitution getting confused in SOLR 5.2.1.
> Cannot load the core, since ${value} is being used for XML parameters for
> system property substitution.
> https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
> Can we support both?
> PS127
> hosp_quality_spec_boost:${pspec}
> This does not work since it thinks it is a System Property.
> We can check System Property and if not defined assume it is in Query, or
> have a new parameter?
> {noformat}
> $ { variable } - for System Properties
> $ { { variable } } - for Query Parameters?
> {noformat}
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7846) QTs with $variable does not work with query parameter substitution
[
https://issues.apache.org/jira/browse/SOLR-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-7846:
Description:
http://yonik.com/solr-query-parameter-substitution/
This is not working as part of QTs in solrconfig.xml due to XML System Property
Substitution getting confused in SOLR 5.2.1.
Cannot load the core, since ${value} is being used for XML parameters for
system property substitution.
https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
Can we support both?
PS127
hosp_quality_spec_boost:${pspec}
This does not work since it thinks it is a System Property.
We can check System Property and if not defined assume it is in Query, or have
a new parameter?
$ { variable } - for System Properties
$ { { variable } } - for Query Parameters?
Thoughts?
was:
http://yonik.com/solr-query-parameter-substitution/
This is not working as part of QTs in solrconfig.xml due to XML System Property
Substitution getting confused in SOLR 5.2.1.
Cannot load the core, since ${value} is being used for XML parameters for
system property substitution.
https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
Can we support both?
PS127
hosp_quality_spec_boost:${pspec}
This does not work since it thinks it is a System Property.
We can check System Property and if not defined assume it is in Query, or have
a new parameter?
${variable} - for System Properties
${{variable}} - for Query Parameters?
Thoughts?
> QTs with $variable does not work with query parameter substitution
> --
>
> Key: SOLR-7846
> URL: https://issues.apache.org/jira/browse/SOLR-7846
> Project: Solr
> Issue Type: Bug
> Reporter: Bill Bell
>
> http://yonik.com/solr-query-parameter-substitution/
> This is not working as part of QTs in solrconfig.xml due to XML System
> Property Substitution getting confused in SOLR 5.2.1.
> Cannot load the core, since ${value} is being used for XML parameters for
> system property substitution.
> https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
> Can we support both?
> PS127
> hosp_quality_spec_boost:${pspec}
> This does not work since it thinks it is a System Property.
> We can check System Property and if not defined assume it is in Query, or
> have a new parameter?
> $ { variable } - for System Properties
> $ { { variable } } - for Query Parameters?
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7846) QTs with $variable does not work with query parameter substitution
Bill Bell created SOLR-7846:
---
Summary: QTs with $variable does not work with query parameter
substitution
Key: SOLR-7846
URL: https://issues.apache.org/jira/browse/SOLR-7846
Project: Solr
Issue Type: Bug
Reporter: Bill Bell
http://yonik.com/solr-query-parameter-substitution/
This is not working as part of QTs in solrconfig.xml due to XML System Property
Substitution getting confused in SOLR 5.2.1.
Cannot load the core, since ${value} is being used for XML parameters for
system property substitution.
https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
Can we support both?
PS127
hosp_quality_spec_boost:${pspec}
This does not work since it thinks it is a System Property.
We can check System Property and if not defined assume it is in Query, or have
a new parameter?
${variable} - for System Properties
${{variable}} - for Query Parameters?
Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7845) sum should treat NULL as 0
Bill Bell created SOLR-7845:
---
Summary: sum should treat NULL as 0
Key: SOLR-7845
URL: https://issues.apache.org/jira/browse/SOLR-7845
Project: Solr
Issue Type: Bug
Reporter: Bill Bell
sum(0,query()) used to treat the NULL values in query as 0. It stopped working
in SOLR 5.
Do we want to fix this?
{{{
http://localhost:8983/solr/select?hqval1=pwid:2&q=*:*&fl=pwid,$y&y=sum(0,query({!lucene%20v=$hqval1}))
}}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7845) sum should treat NULL as 0
[
https://issues.apache.org/jira/browse/SOLR-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-7845:
Description:
sum(0,query()) used to treat the NULL values in query as 0. It stopped working
in SOLR 5.
Do we want to fix this?
http://localhost:8983/solr/select?hqval1=pwid:2&q=*:*&fl=pwid,$y&y=sum(0,query({!lucene%20v=$hqval1}))
was:
sum(0,query()) used to treat the NULL values in query as 0. It stopped working
in SOLR 5.
Do we want to fix this?
{{{
http://localhost:8983/solr/select?hqval1=pwid:2&q=*:*&fl=pwid,$y&y=sum(0,query({!lucene%20v=$hqval1}))
}}}
> sum should treat NULL as 0
> --
>
> Key: SOLR-7845
> URL: https://issues.apache.org/jira/browse/SOLR-7845
> Project: Solr
> Issue Type: Bug
>Reporter: Bill Bell
>
> sum(0,query()) used to treat the NULL values in query as 0. It stopped
> working in SOLR 5.
> Do we want to fix this?
> http://localhost:8983/solr/select?hqval1=pwid:2&q=*:*&fl=pwid,$y&y=sum(0,query({!lucene%20v=$hqval1}))
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7827) BSON Response Writer
Bill Bell created SOLR-7827: --- Summary: BSON Response Writer Key: SOLR-7827 URL: https://issues.apache.org/jira/browse/SOLR-7827 Project: Solr Issue Type: New Feature Reporter: Bill Bell Why not support BSON (we recently added SMILE). BSON and Smile are two distinct binary formats. They are related in that they are both based on the logical format of JSON (i.e., key-value objects) but they are distinct in that they write incompatible binary formats (you can neither directly read Smile as BSON nor vice-versa.) They also have different incompatible features (e.g., BSON defines a date type, while Smile does not as far as I can tell.) BSON is the binary serialization used by MongoDB for network transfer and disk serialization. Smile is the binary JSON format used by the Jackson project. I don't know why these two projects created different binary formats with such similar purposes. One reason might be that the MongoDB project required dates for their particular application, whereas the JSON format lacks a date type, and adherance to the JSON format may have been the reason that the Smile format does not include a date type. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3393) Implement an optimized LFUCache
[ https://issues.apache.org/jira/browse/SOLR-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616110#comment-14616110 ] Bill Bell commented on SOLR-3393: - Let's get this done. What is remaining? O(1) sounds great. > Implement an optimized LFUCache > --- > > Key: SOLR-3393 > URL: https://issues.apache.org/jira/browse/SOLR-3393 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 3.6, 4.0-ALPHA >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Fix For: 4.9, Trunk > > Attachments: SOLR-3393-4x-withdecay.patch, > SOLR-3393-trunk-withdecay.patch, SOLR-3393.patch, SOLR-3393.patch, > SOLR-3393.patch, SOLR-3393.patch, SOLR-3393.patch, SOLR-3393.patch, > SOLR-3393.patch > > > SOLR-2906 gave us an inefficient LFU cache modeled on > FastLRUCache/ConcurrentLRUCache. It could use some serious improvement. The > following project includes an Apache 2.0 licensed O(1) implementation. The > second link is the paper (PDF warning) it was based on: > https://github.com/chirino/hawtdb > http://dhruvbird.com/lfu.pdf > Using this project and paper, I will attempt to make a new O(1) cache called > FastLFUCache that is modeled on LRUCache.java. This will (for now) leave the > existing LFUCache/ConcurrentLFUCache implementation in place. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3963) SOLR: map() does not allow passing sub-functions in 4,5 parameters
[ https://issues.apache.org/jira/browse/SOLR-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14612839#comment-14612839 ] Bill Bell commented on SOLR-3963: - This is still a valid enhancement > SOLR: map() does not allow passing sub-functions in 4,5 parameters > -- > > Key: SOLR-3963 > URL: https://issues.apache.org/jira/browse/SOLR-3963 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Bill Bell >Assignee: Hoss Man >Priority: Minor > Attachments: SOLR-3963.2.patch > > > I want to do: > boost=map(achievement_count,1,1000,recip(achievement_count,-.5,10,25),1) > I want to return recip(achievement_count,-.5,10,25) if achievement_count is > between 1 and 1,000. FOr any other values I want to return 1. > I cannot get it to work. I get the error below. Interesting this does work: > boost=recip(map(achievement_count,0,0,-200),-.5,10,25) > It almost appears that map() cannot take a function. > Specified argument was out of the range of valid values. > Parameter name: value > Description: An unhandled exception occurred during the execution of the > current web request. Please review the stack trace for more information about > the error and where it originated in the code. > Exception Details: System.ArgumentOutOfRangeException: Specified argument was > out of the range of valid values. > Parameter name: value > Source Error: > An unhandled exception was generated during the execution of the current web > request. Information regarding the origin and location of the exception can > be identified using the exception stack trace below. > Stack Trace: > [ArgumentOutOfRangeException: Specified argument was out of the range of > valid values. > Parameter name: value] >System.Web.HttpResponse.set_StatusDescription(String value) +5200522 >FacilityService.Controllers.FacilityController.ActionCompleted(String > actionName, IFacilityResults results) +265 > > FacilityService.Controllers.FacilityController.SearchByPointCompleted(IFacilityResults > results) +25 >lambda_method(Closure , ControllerBase , Object[] ) +114 >System.Web.Mvc.Async.<>c__DisplayClass7.b__5(IAsyncResult > asyncResult) +283 > > System.Web.Mvc.Async.<>c__DisplayClass41.b__40(IAsyncResult > asyncResult) +22 > > System.Web.Mvc.Async.<>c__DisplayClass3b.b__35() > +120 > > System.Web.Mvc.Async.<>c__DisplayClass51.b__4b() > +452 > > System.Web.Mvc.Async.<>c__DisplayClass39.b__38(IAsyncResult > asyncResult) +15 >System.Web.Mvc.Async.<>c__DisplayClass2c.b__22() +33 > > System.Web.Mvc.Async.<>c__DisplayClass27.b__24(IAsyncResult > asyncResult) +240 >System.Web.Mvc.<>c__DisplayClass19.b__14(IAsyncResult > asyncResult) +28 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.Mvc.AsyncController.EndExecuteCore(IAsyncResult asyncResult) +63 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.Mvc.<>c__DisplayClassb.b__4(IAsyncResult > asyncResult) +42 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult > ar) +282 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7650) Allow wildcard on fl for Raw JSON/XML
[ https://issues.apache.org/jira/browse/SOLR-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14612836#comment-14612836 ] Bill Bell commented on SOLR-7650: - thoughts? > Allow wildcard on fl for Raw JSON/XML > - > > Key: SOLR-7650 > URL: https://issues.apache.org/jira/browse/SOLR-7650 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.2 >Reporter: Bill Bell > > We would like to allow for * in the field list when using [json]. > For example: > http://hgsolr2devmstr:8983/solr/select?q=*:*&wt=json&fl=*_json:[json] > This 400 errors/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7539) Add a QueryAutofilteringComponent for query introspection using indexed metadata
[ https://issues.apache.org/jira/browse/SOLR-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14612831#comment-14612831 ] Bill Bell commented on SOLR-7539: - +1 > Add a QueryAutofilteringComponent for query introspection using indexed > metadata > > > Key: SOLR-7539 > URL: https://issues.apache.org/jira/browse/SOLR-7539 > Project: Solr > Issue Type: New Feature >Reporter: Ted Sullivan >Priority: Minor > Fix For: Trunk > > Attachments: SOLR-7539.patch, SOLR-7539.patch, SOLR-7539.patch > > > The Query Autofiltering Component provides a method of inferring user intent > by matching noun phrases that are typically used for faceted-navigation into > Solr filter or boost queries (depending on configuration settings) so that > more precise user queries can be met with more precise results. > The algorithm uses a "longest contiguous phrase match" strategy which allows > it to disambiguate queries where single terms are ambiguous but phrases are > not. It will work when there is structured information in the form of String > fields that are normally used for faceted navigation. It works across fields > by building a map of search term to index field using the Lucene FieldCache > (UninvertingReader). This enables users to create free text, multi-term > queries that combine attributes across facet fields - as if they had searched > and then navigated through several facet layers. To address the problem of > exact-match only semantics of String fields, support for synonyms (including > multi-term synonyms) and stemming was added. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7136) Add an AutoPhrasing TokenFilter
[ https://issues.apache.org/jira/browse/SOLR-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14612829#comment-14612829 ] Bill Bell commented on SOLR-7136: - +1 Let' get it committed > 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 > Attachments: 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 (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-7674) Content-Type: json gives null issue when not sending Body
[ https://issues.apache.org/jira/browse/SOLR-7674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell closed SOLR-7674. --- Resolution: Fixed SOLR-7574 > Content-Type: json gives null issue when not sending Body > - > > Key: SOLR-7674 > URL: https://issues.apache.org/jira/browse/SOLR-7674 > Project: Solr > Issue Type: Bug > Reporter: Bill Bell > Attachments: SOLR-7674.patch > > > curl -H "Content-Type: application/json" > 'http://localhost:8983/solr/select?q=*:*' > This fails with a NULL error in mergeMap. > Here is a patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7674) Content-Type: json gives null issue when not sending Body
[ https://issues.apache.org/jira/browse/SOLR-7674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-7674: Attachment: SOLR-7674.patch Check for null > Content-Type: json gives null issue when not sending Body > - > > Key: SOLR-7674 > URL: https://issues.apache.org/jira/browse/SOLR-7674 > Project: Solr > Issue Type: Bug > Reporter: Bill Bell > Attachments: SOLR-7674.patch > > > curl -H "Content-Type: application/json" > 'http://localhost:8983/solr/select?q=*:*' > This fails with a NULL error in mergeMap. > Here is a patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7674) Content-Type: json gives null issue when not sending Body
Bill Bell created SOLR-7674: --- Summary: Content-Type: json gives null issue when not sending Body Key: SOLR-7674 URL: https://issues.apache.org/jira/browse/SOLR-7674 Project: Solr Issue Type: Bug Reporter: Bill Bell curl -H "Content-Type: application/json" 'http://localhost:8983/solr/select?q=*:*' This fails with a NULL error in mergeMap. Here is a patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7650) Allow wildcard on fl for Raw JSON/XML
Bill Bell created SOLR-7650: --- Summary: Allow wildcard on fl for Raw JSON/XML Key: SOLR-7650 URL: https://issues.apache.org/jira/browse/SOLR-7650 Project: Solr Issue Type: Improvement Affects Versions: 5.2 Reporter: Bill Bell We would like to allow for * in the field list when using [json]. For example: http://hgsolr2devmstr:8983/solr/select?q=*:*&wt=json&fl=*_json:[json] This 400 errors/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7588) naturalSort.js is provided as coffeescript instead of plain javascript
[
https://issues.apache.org/jira/browse/SOLR-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-7588:
Attachment: SOLR-7588.patch
Patch for naturalSort.js for 5.2
> naturalSort.js is provided as coffeescript instead of plain javascript
> --
>
> Key: SOLR-7588
> URL: https://issues.apache.org/jira/browse/SOLR-7588
> Project: Solr
> Issue Type: Bug
> Components: web gui
>Affects Versions: Trunk, 5.2
> Environment: Fedora 21
> openjdk version "1.8.0_45"
> OpenJDK Runtime Environment (build 1.8.0_45-b14)
> OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode)
>Reporter: Derek Wood
> Attachments: SOLR-7588.patch
>
>
> The Dataimport tab of a core will hang with a loading screen or display the
> previously accessed tab instead of showing the expected dataimport screen.
> The console in Chrome has the following error log, but it's obvious to me
> that it's trying to run un-transpiled coffeescript:
> {noformat}
> naturalSort.js?_=6.0.0:30 Uncaught SyntaxError: Unexpected token ILLEGAL
> jquery.sammy.js?_=6.0.0:120 [Fri May 22 2015 23:36:59 GMT-0700 (MST)]
> runRoute get #/db/dataimport
> dataimport.js?_=6.0.0:48 Uncaught ReferenceError: naturalSort is not defined
> {noformat}
> The file in question can be viewed here:
> https://svn.apache.org/viewvc/lucene/dev/trunk/solr/webapp/web/js/lib/naturalSort.js?view=markup
> I was able to verify this in my own build as well as the nightly builds
> hosted on the Apache Jenkins server with the default DIH example ({{bin/solr
> start -e dih}}).
> After replacing the coffeescript file with one transpiled to javascript
> (available at
> https://github.com/jarinudom/naturalSort.js/blob/master/dist/naturalSort.js),
> the dataimport tab worked as expected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7574) NullPointerException in RequestUtil.mergeJSON
[
https://issues.apache.org/jira/browse/SOLR-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14576570#comment-14576570
]
Bill Bell commented on SOLR-7574:
-
Yonik ? Thoughts?
> NullPointerException in RequestUtil.mergeJSON
> -
>
> Key: SOLR-7574
> URL: https://issues.apache.org/jira/browse/SOLR-7574
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.1
>Reporter: Alexey Serba
>Priority: Trivial
>
> {noformat:title="Steps to reproduce"}
> bin/solr start
> bin/solr create_core -c test
> curl -H 'Content-type: application/json'
> 'http://localhost:8983/solr/test/select?q=*:*&rows=10&wt=json'
> {noformat}
> {noformat:title="Exception"}
> ERROR - 2015-05-19 21:02:47.144; [ test]
> org.apache.solr.common.SolrException; null:java.lang.NullPointerException
> at
> org.apache.solr.request.json.ObjectUtil$ConflictHandler.mergeMap(ObjectUtil.java:60)
> at
> org.apache.solr.request.json.ObjectUtil.mergeObjects(ObjectUtil.java:114)
> at
> org.apache.solr.request.json.RequestUtil.mergeJSON(RequestUtil.java:259)
> at
> org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:176)
> at
> org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:166)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:140)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> ...
> {noformat}
> While there's no really any point in specifying content-type header with no
> content stream, but one can forget to remove this when trying different
> commands with curl / script.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7644) Add Common Daemons to bin/run for -d
[ https://issues.apache.org/jira/browse/SOLR-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14576364#comment-14576364 ] Bill Bell commented on SOLR-7644: - Guillaume Belrose guillaume.belr...@quantel.com via lucene.apache.org Jun 4 (3 days ago) to solr-user Hi, I've successfully used procrun (see http://commons.apache.org/proper/commons-daemon/procrun.html) to wrap Solr 5.1 solr.cmd script as a Windows service (I’ve only tested on Windows 2008 R2). Previously, I was using Procrun to manage Jetty services running the Solr.war from older versions but with a bit a tweaking, I was able to wrap the new Solr 5.1.0 scripts. I roughly did the following: -download and unzip the Solr 5.1.0 distribution to a local folder (i.e. c:\opt ) -download and unzip the Apache Commons Daemon .zip file (from http://commons.apache.org/proper/commons-daemon/download_daemon.cgi) in my solr local folder (i.e. c:\opt\solr-5.1.0) -run the batch file [1]. All of this was done through Ansible Playbooks which is the tool I use for configuration management on Windows and Linux. Cheers, Guillaume. [1] @echo off set SERVICE_NAME=solr set SERVICE_HOME=c:\opt\solr-5.1.0 set PR_INSTALL=%SERVICE_HOME%\amd64\prunsrv.exe @REM Service Log Configuration set PR_LOGPREFIX=%SERVICE_NAME% set PR_LOGPATH=%SERVICE_HOME%\logs set PR_STDOUTPUT=auto set PR_STDERROR=auto set PR_LOGLEVEL=Debug set PR_STARTUP=auto set PR_STARTMODE=exe set PR_STARTIMAGE=%SERVICE_HOME%\bin\solr.cmd set PR_STARTPARAMS=start @REM Shutdown Configuration set PR_STOPMODE=exe set PR_STOPIMAGE=%SERVICE_HOME%\bin\solr.cmd set PR_STOPPARAMS=stop -p 8983 %PR_INSTALL% //IS/%SERVICE_NAME% ^ --Description="Solr-5.1.0" ^ --DisplayName="%SERVICE_NAME%" ^ --Install="%PR_INSTALL%" ^ --Startup="%PR_STARTUP%" ^ --LogPath="%PR_LOGPATH%" ^ --LogPrefix="%PR_LOGPREFIX%" ^ --LogLevel="%PR_LOGLEVEL%" ^ --StdOutput="%PR_STDOUTPUT%" ^ --StdError="%PR_STDERROR%" ^ --StartMode="%PR_STARTMODE%" ^ --StartImage="%PR_STARTIMAGE%" ^ --StartParams="%PR_STARTPARAMS%" ^ --StopMode="%PR_STOPMODE%" ^ --StopImage="%PR_STOPIMAGE%" ^ --StopParams="%PR_STOPPARAMS%" if not errorlevel 1 goto installed echo Failed to install "%SERVICE_NAME%" service. Refer to log in %PR_LOGPATH% exit /B 1 :installed echo The Service "%SERVICE_NAME%" has been installed exit /B 0 > Add Common Daemons to bin/run for -d > > > Key: SOLR-7644 > URL: https://issues.apache.org/jira/browse/SOLR-7644 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.2 >Reporter: Bill Bell > > Why don't we change the bin/run -d to have Common Daemons? This would be a > great enhancement to SOLR 5.x. > Common Daemons. > http://commons.apache.org/proper/commons-daemon/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7644) Add Common Daemons to bin/run for -d
Bill Bell created SOLR-7644: --- Summary: Add Common Daemons to bin/run for -d Key: SOLR-7644 URL: https://issues.apache.org/jira/browse/SOLR-7644 Project: Solr Issue Type: Improvement Affects Versions: 5.2 Reporter: Bill Bell Why don't we change the bin/run -d to have Common Daemons? This would be a great enhancement to SOLR 5.x. Common Daemons. http://commons.apache.org/proper/commons-daemon/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7634) Upgrade Jetty to 9.2.11.v20150529
Bill Bell created SOLR-7634: --- Summary: Upgrade Jetty to 9.2.11.v20150529 Key: SOLR-7634 URL: https://issues.apache.org/jira/browse/SOLR-7634 Project: Solr Issue Type: Improvement Reporter: Bill Bell Priority: Minor Fix For: 5.3 Please upgrade Jetty to: jetty-distribution-9.2.11.v20150529 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3
[
https://issues.apache.org/jira/browse/SOLR-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568519#comment-14568519
]
Bill Bell commented on SOLR-7339:
-
http://central.maven.org/maven2/org/eclipse/jetty/jetty-distribution/9.3.0.RC0/
RC0 released
> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
> Issue Type: Improvement
>Reporter: Gregg Donovan
> Attachments: SOLR-7339.patch
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699]
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading
> Jetty. The server configuration would need to change and a new HTTP client
> ([Jetty's own
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2],
> [Square's OkHttp|http://square.github.io/okhttp/],
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need
> to be selected and wired up. Perhaps this is worthy of a branch?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568493#comment-14568493 ] Bill Bell commented on SOLR-4839: - jetty-distribution-9.2.11.v20150529.zip ? 9.2.11 is released. > Jetty 9 > --- > > Key: SOLR-4839 > URL: https://issues.apache.org/jira/browse/SOLR-4839 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell >Assignee: Shalin Shekhar Mangar > Fix For: Trunk, 5.2 > > Attachments: SOLR-4839-branch_5x.patch, > SOLR-4839-conform-jetty9_2_10.patch, SOLR-4839-conform-jetty9_2_10.patch, > SOLR-4839-fix-eclipse.patch, SOLR-4839-jetty9.2.10, > SOLR-4839-mod-JettySolrRunner.patch, > SOLR-4839-separate-client-ssl-options.patch, > SOLR-4839-ssl-support_patch.patch, SOLR-4839-ssl-support_patch.patch, > SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, > SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, > SOLR-4839.patch > > > Implement Jetty 9 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7574) NullPointerException in RequestUtil.mergeJSON
[
https://issues.apache.org/jira/browse/SOLR-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14551851#comment-14551851
]
Bill Bell commented on SOLR-7574:
-
yeah this new behavior is breaking a ton of our code
> NullPointerException in RequestUtil.mergeJSON
> -
>
> Key: SOLR-7574
> URL: https://issues.apache.org/jira/browse/SOLR-7574
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.1
>Reporter: Alexey Serba
>Priority: Trivial
>
> {noformat:title="Steps to reproduce"}
> bin/solr start
> bin/solr create_core -c test
> curl -H 'Content-type: application/json'
> 'http://localhost:8983/solr/test/select?q=*:*&rows=10&wt=json'
> {noformat}
> {noformat:title="Exception"}
> ERROR - 2015-05-19 21:02:47.144; [ test]
> org.apache.solr.common.SolrException; null:java.lang.NullPointerException
> at
> org.apache.solr.request.json.ObjectUtil$ConflictHandler.mergeMap(ObjectUtil.java:60)
> at
> org.apache.solr.request.json.ObjectUtil.mergeObjects(ObjectUtil.java:114)
> at
> org.apache.solr.request.json.RequestUtil.mergeJSON(RequestUtil.java:259)
> at
> org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:176)
> at
> org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:166)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:140)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> ...
> {noformat}
> While there's no really any point in specifying content-type header with no
> content stream, but one can forget to remove this when trying different
> commands with curl / script.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-4685: Attachment: SOLR-4685.5.1.patch Patch for 5.1 > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell >Priority: Minor > Attachments: SOLR-4685.1.patch, SOLR-4685.5.1.patch, > SOLR-4685.SOLR_4_5.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4787) Join Contrib
[
https://issues.apache.org/jira/browse/SOLR-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345727#comment-14345727
]
Bill Bell commented on SOLR-4787:
-
To be consistent can we add FQ?
Based on post by Yonik:
The join qparser has no "fq" parameter, so that is ignored.
-Yonik
http://heliosearch.org - native code faceting, facet functions,
sub-facets, off-heap data
> Join Contrib
>
>
> Key: SOLR-4787
> URL: https://issues.apache.org/jira/browse/SOLR-4787
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.2.1
>Reporter: Joel Bernstein
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-4787-deadlock-fix.patch,
> SOLR-4787-pjoin-long-keys.patch, SOLR-4787-with-testcase-fix.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4797-hjoin-multivaluekeys-nestedJoins.patch,
> SOLR-4797-hjoin-multivaluekeys-trunk.patch
>
>
> This contrib provides a place where different join implementations can be
> contributed to Solr. This contrib currently includes 3 join implementations.
> The initial patch was generated from the Solr 4.3 tag. Because of changes in
> the FieldCache API this patch will only build with Solr 4.2 or above.
> *HashSetJoinQParserPlugin aka hjoin*
> The hjoin provides a join implementation that filters results in one core
> based on the results of a search in another core. This is similar in
> functionality to the JoinQParserPlugin but the implementation differs in a
> couple of important ways.
> The first way is that the hjoin is designed to work with int and long join
> keys only. So, in order to use hjoin, int or long join keys must be included
> in both the to and from core.
> The second difference is that the hjoin builds memory structures that are
> used to quickly connect the join keys. So, the hjoin will need more memory
> then the JoinQParserPlugin to perform the join.
> The main advantage of the hjoin is that it can scale to join millions of keys
> between cores and provide sub-second response time. The hjoin should work
> well with up to two million results from the fromIndex and tens of millions
> of results from the main query.
> The hjoin supports the following features:
> 1) Both lucene query and PostFilter implementations. A *"cost"* > 99 will
> turn on the PostFilter. The PostFilter will typically outperform the Lucene
> query when the main query results have been narrowed down.
> 2) With the lucene query implementation there is an option to build the
> filter with threads. This can greatly improve the performance of the query if
> the main query index is very large. The "threads" parameter turns on
> threading. For example *threads=6* will use 6 threads to build the filter.
> This will setup a fixed threadpool with six threads to handle all hjoin
> requests. Once the threadpool is created the hjoin will always use it to
> build the filter. Threading does not come into play with the PostFilter.
> 3) The *size* local parameter can be used to set the initial size of the
> hashset used to perform the join. If this is set above the number of results
> from the fromIndex then the you can avoid hashset resizing which improves
> performance.
> 4) Nested filter queries. The local parameter "fq" can be used to nest a
> filter query within the join. The nested fq will filter the results of the
> join query. This can point to another join to support nested joins.
> 5) Full caching support for the lucene query implementation. The filterCache
> and queryResultCache should work properly even with deep nesting of joins.
> Only the queryResultCache comes into play with the PostFilter implementation
> because PostFilters are not cacheable in the filterCache.
> The syntax of the hjoin is similar to the JoinQParserPlugin except that the
> plugin is referenced by the string "hjoin" rather then "join".
> fq=\{!hjoin fromIndex=collection2 from=id_i to=id_i threads=6
> fq=$qq\}user:customer1&qq=group:5
> The example filter query above will search the fromIndex (collection2) for
> "user:customer1" applying the local fq parameter to filter the results. The
> lucene filter query will be built using 6 threads. This query will generate a
> list of values from the "from" field that will be used to filter the mai
[jira] [Commented] (SOLR-4787) Join Contrib
[
https://issues.apache.org/jira/browse/SOLR-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344601#comment-14344601
]
Bill Bell commented on SOLR-4787:
-
This seems like a no-brainer. Can we commit this into 5.xxx ?
> Join Contrib
>
>
> Key: SOLR-4787
> URL: https://issues.apache.org/jira/browse/SOLR-4787
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.2.1
>Reporter: Joel Bernstein
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-4787-deadlock-fix.patch,
> SOLR-4787-pjoin-long-keys.patch, SOLR-4787-with-testcase-fix.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4797-hjoin-multivaluekeys-nestedJoins.patch,
> SOLR-4797-hjoin-multivaluekeys-trunk.patch
>
>
> This contrib provides a place where different join implementations can be
> contributed to Solr. This contrib currently includes 3 join implementations.
> The initial patch was generated from the Solr 4.3 tag. Because of changes in
> the FieldCache API this patch will only build with Solr 4.2 or above.
> *HashSetJoinQParserPlugin aka hjoin*
> The hjoin provides a join implementation that filters results in one core
> based on the results of a search in another core. This is similar in
> functionality to the JoinQParserPlugin but the implementation differs in a
> couple of important ways.
> The first way is that the hjoin is designed to work with int and long join
> keys only. So, in order to use hjoin, int or long join keys must be included
> in both the to and from core.
> The second difference is that the hjoin builds memory structures that are
> used to quickly connect the join keys. So, the hjoin will need more memory
> then the JoinQParserPlugin to perform the join.
> The main advantage of the hjoin is that it can scale to join millions of keys
> between cores and provide sub-second response time. The hjoin should work
> well with up to two million results from the fromIndex and tens of millions
> of results from the main query.
> The hjoin supports the following features:
> 1) Both lucene query and PostFilter implementations. A *"cost"* > 99 will
> turn on the PostFilter. The PostFilter will typically outperform the Lucene
> query when the main query results have been narrowed down.
> 2) With the lucene query implementation there is an option to build the
> filter with threads. This can greatly improve the performance of the query if
> the main query index is very large. The "threads" parameter turns on
> threading. For example *threads=6* will use 6 threads to build the filter.
> This will setup a fixed threadpool with six threads to handle all hjoin
> requests. Once the threadpool is created the hjoin will always use it to
> build the filter. Threading does not come into play with the PostFilter.
> 3) The *size* local parameter can be used to set the initial size of the
> hashset used to perform the join. If this is set above the number of results
> from the fromIndex then the you can avoid hashset resizing which improves
> performance.
> 4) Nested filter queries. The local parameter "fq" can be used to nest a
> filter query within the join. The nested fq will filter the results of the
> join query. This can point to another join to support nested joins.
> 5) Full caching support for the lucene query implementation. The filterCache
> and queryResultCache should work properly even with deep nesting of joins.
> Only the queryResultCache comes into play with the PostFilter implementation
> because PostFilters are not cacheable in the filterCache.
> The syntax of the hjoin is similar to the JoinQParserPlugin except that the
> plugin is referenced by the string "hjoin" rather then "join".
> fq=\{!hjoin fromIndex=collection2 from=id_i to=id_i threads=6
> fq=$qq\}user:customer1&qq=group:5
> The example filter query above will search the fromIndex (collection2) for
> "user:customer1" applying the local fq parameter to filter the results. The
> lucene filter query will be built using 6 threads. This query will generate a
> list of values from the "from" field that will be used to filter the main
> query. Only records from the main query, where the "to" field is present in
> the "from" list will be included in the results.
> The s
[jira] [Commented] (SOLR-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272811#comment-14272811 ] Bill Bell commented on SOLR-4839: - Are we going with Jetty 9.2? https://webtide.com/jetty-9-2-0-released/ > Jetty 9 > --- > > Key: SOLR-4839 > URL: https://issues.apache.org/jira/browse/SOLR-4839 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell >Assignee: Shalin Shekhar Mangar > Fix For: 5.0, Trunk > > Attachments: SOLR-4839-fix-eclipse.patch, > SOLR-4839-mod-JettySolrRunner.patch, SOLR-4839.patch, SOLR-4839.patch, > SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, > SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch > > > Implement Jetty 9 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5580) NPE when create a core with both explicite shard and coreNodeName
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858090#comment-13858090
]
Bill Bell commented on SOLR-5580:
-
This looks good to me. I also like the log.info()
> NPE when create a core with both explicite shard and coreNodeName
> --
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
> Labels: core
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
> if (sliceName !=null && collectionExists &&
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
> log.info("core_deleted . Just return");
> return state;
> }
> }
> -
> the slice needs to be checked null .because when create a new core with both
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)
> may return a null.So it needs to be checked ,or there will be an
> NullpointException
> -
> if (sliceName !=null && collectionExists &&
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
> log.info("core_deleted . Just return");
> return state;
> }
> }
> -
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5463) Provide cursor/token based "searchAfter" support that works with arbitrary sorting (ie: "deep paging")
[ https://issues.apache.org/jira/browse/SOLR-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13845882#comment-13845882 ] Bill Bell commented on SOLR-5463: - How does this work across slaves? Won't we need to have set a sticky session - or are you hashing the key for the slaves? > Provide cursor/token based "searchAfter" support that works with arbitrary > sorting (ie: "deep paging") > -- > > Key: SOLR-5463 > URL: https://issues.apache.org/jira/browse/SOLR-5463 > Project: Solr > Issue Type: New Feature >Reporter: Hoss Man >Assignee: Hoss Man > Attachments: SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, > SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, > SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, > SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, > SOLR-5463__straw_man.patch > > > I'd like to revist a solution to the problem of "deep paging" in Solr, > leveraging an HTTP based API similar to how IndexSearcher.searchAfter works > at the lucene level: require the clients to provide back a token indicating > the sort values of the last document seen on the previous "page". This is > similar to the "cursor" model I've seen in several other REST APIs that > support "pagnation" over a large sets of results (notable the twitter API and > it's "since_id" param) except that we'll want something that works with > arbitrary multi-level sort critera that can be either ascending or descending. > SOLR-1726 laid some initial ground work here and was commited quite a while > ago, but the key bit of argument parsing to leverage it was commented out due > to some problems (see comments in that issue). It's also somewhat out of > date at this point: at the time it was commited, IndexSearcher only supported > searchAfter for simple scores, not arbitrary field sorts; and the params > added in SOLR-1726 suffer from this limitation as well. > --- > I think it would make sense to start fresh with a new issue with a focus on > ensuring that we have deep paging which: > * supports arbitrary field sorts in addition to sorting by score > * works in distributed mode -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5543) solr.xml duplicat eentries after SWAP 4.6
Bill Bell created SOLR-5543: --- Summary: solr.xml duplicat eentries after SWAP 4.6 Key: SOLR-5543 URL: https://issues.apache.org/jira/browse/SOLR-5543 Project: Solr Issue Type: Bug Affects Versions: 4.6 Reporter: Bill Bell We are having issues with SWAP CoreAdmin in 4.6. Using legacy solr.xml we issue a COreodmin SWAP, and we want it persistent. It has been running flawless since 4.5. Now it creates duplicate lines in solr.xml. Even the example multi core schema in doesn't work with persistent="true" - it creates duplicate lines in solr.xml. -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5212) java 7u40 causes sigsegv and corrupt term vectors
[ https://issues.apache.org/jira/browse/LUCENE-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793037#comment-13793037 ] Bill Bell commented on LUCENE-5212: --- It appears this happens on 7u40 64-bit too. See https://bugs.openjdk.java.net/browse/JDK-8024830 Am I reading this wrong? Start failing around hs24-b21: [junit4] # SIGSEGV (0xb) at pc=0xfd7ff91d9f7d, pid=23810, tid=343 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b54) [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b21 mixed mode solaris-amd64 ) [junit4] # Problematic frame: [junit4] # J org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get(I)Lorg/apache/lucene/index/Fields; [junit4] # Note, first 7u40 build b01 has hs24-b24. Next, I will try to find changeset. > java 7u40 causes sigsegv and corrupt term vectors > - > > Key: LUCENE-5212 > URL: https://issues.apache.org/jira/browse/LUCENE-5212 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: crashFaster2.0.patch, crashFaster.patch, > hs_err_pid32714.log, jenkins.txt > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2548) Multithreaded faceting
[ https://issues.apache.org/jira/browse/SOLR-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790041#comment-13790041 ] Bill Bell commented on SOLR-2548: - When using facet.threads=1000 I am not seeing any better performance. 1. Does it work on facet.query as well as facet.field? 2. If I only have 1 facet.field - adding threads will it do anything? 3. Will it help more on multiple facet.field? 4. Does it help with facet.method=fc/fcs/ or enum? > Multithreaded faceting > -- > > Key: SOLR-2548 > URL: https://issues.apache.org/jira/browse/SOLR-2548 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 3.1 >Reporter: Janne Majaranta >Assignee: Erick Erickson >Priority: Minor > Labels: facet > Fix For: 4.5, 5.0 > > Attachments: SOLR-2548_4.2.1.patch, SOLR-2548_for_31x.patch, > SOLR-2548_multithreaded_faceting,_dsmiley.patch, > SOLR-2548_multithreaded_faceting,_dsmiley.patch, SOLR-2548.patch, > SOLR-2548.patch, SOLR-2548.patch, SOLR-2548.patch, SOLR-2548.patch, > SOLR-2548.patch > > > Add multithreading support for faceting. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-4685: Attachment: SOLR-4685.SOLR_4_5.patch For recent release of SOLR 4.5 > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell >Assignee: Erik Hatcher >Priority: Minor > Attachments: SOLR-4685.1.patch, SOLR-4685.SOLR_4_5.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4692) JSON Field transformer for DIH
[ https://issues.apache.org/jira/browse/SOLR-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13787767#comment-13787767 ] Bill Bell commented on SOLR-4692: - This is more of a contrib to DIH. Would love to see it added as a feature since it is simple. Take XML and convert to JSON and store it. IF not - I'll keep using it on my projects... No harm for me. > JSON Field transformer for DIH > -- > > Key: SOLR-4692 > URL: https://issues.apache.org/jira/browse/SOLR-4692 > Project: Solr > Issue Type: Bug >Reporter: Bill Bell > Attachments: JSONTransformer.java, JSONTransform.jar, xml.jar > > > This works in conjunction with SOLR-4685. > Takes an XML field from SQL / manually and adds it as a JSON field. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13787766#comment-13787766 ] Bill Bell commented on SOLR-4685: - Can we please commit this ? I am using it in PROD for last few months and it works great. Jack: XML, PHP, Ruby don't have this issue since if the field is XML, and you use wt=xml you get XML normally out of it. But when you set wt=json and have a field that is JSON string, it escapes everything. There is no hard in this. It just stops the escaping of any fields that end with json.fsuffix=_json - basically ending with _json. I need all the other features of wt=json, but I also need the ability to NOT escape a JSON string field. If someone could figure out a simple way that does not waste resources figuring out which fields are already JSON when you use wt=json, that would be preferrable - to turn off escaping of that field. But until we have that I am proposing this feature. Which has NO hard and it a simple feature to maintain - "turn off escaping of a field when using wt=json". Can we vote on it? > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement >Reporter: Bill Bell >Assignee: Erik Hatcher >Priority: Minor > Attachments: SOLR-4685.1.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2345) Extend geodist() to support MultiValued lat long field
[
https://issues.apache.org/jira/browse/SOLR-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754880#comment-13754880
]
Bill Bell commented on SOLR-2345:
-
We are suing it in PROD, and so far no issues
> Extend geodist() to support MultiValued lat long field
> --
>
> Key: SOLR-2345
> URL: https://issues.apache.org/jira/browse/SOLR-2345
> Project: Solr
> Issue Type: New Feature
> Components: spatial
>Reporter: Bill Bell
>Assignee: David Smiley
> Fix For: 4.5, 5.0
>
> Attachments: SOLR-2345_geodist_refactor.patch,
> SOLR-2345_geodist_support_for_RPT.patch
>
>
> Extend geodist() and {!geofilt} to support a multiValued lat,long field
> without using geohash.
> sort=geodist() asc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-64) strict hierarchical facets
[ https://issues.apache.org/jira/browse/SOLR-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754875#comment-13754875 ] Bill Bell commented on SOLR-64: --- This is plus 2 years old... Are we fixing it? > strict hierarchical facets > -- > > Key: SOLR-64 > URL: https://issues.apache.org/jira/browse/SOLR-64 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Yonik Seeley > Fix For: 4.5, 5.0 > > Attachments: SOLR-64_3.1.0.patch, SOLR-64.patch, SOLR-64.patch, > SOLR-64.patch, SOLR-64.patch > > > Strict Facet Hierarchies... each tag has at most one parent (a tree). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5170) Spatial multi-value distance sort via DocValues
[
https://issues.apache.org/jira/browse/SOLR-5170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13748318#comment-13748318
]
Bill Bell commented on SOLR-5170:
-
David,
How many points is the limit when it "adds up"? Does it give an OOM exception?
Or does it just take longer and longer to respond?
In most use cases there is almost no need to cache the geo spatial search
results, since most users are running queries from multiple locations (with GEO
IP) targeting. At least that is our use case. If the corpus of points is high,
is there an approximation that can be use to reduce it and then run the Circle
radius? For example fq={!cache=false cost=10}lat:[X to Y] AND long:[X1 to Y1]
and apply the fq={!geofilt cost=100} or geodist ?
We have found that doing that speeds things up... Wonder if the code could just
do that for us ?
> Spatial multi-value distance sort via DocValues
> ---
>
> Key: SOLR-5170
> URL: https://issues.apache.org/jira/browse/SOLR-5170
> Project: Solr
> Issue Type: New Feature
> Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR-5170_spatial_multi-value_sort_via_docvalues.patch
>
>
> The attached patch implements spatial multi-value distance sorting. In other
> words, a document can have more than one point per field, and using a
> provided function query, it will return the distance to the closest point.
> The data goes into binary DocValues, and as-such it's pretty friendly to
> realtime search requirements, and it only uses 8 bytes per point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4698) Overhaul ShapeFieldCache because its a memory pig
[ https://issues.apache.org/jira/browse/LUCENE-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13743072#comment-13743072 ] Bill Bell commented on LUCENE-4698: --- This JIRA ticket is extremely important when using this ShapeFieldCache... David is there a way to : 1. Use FieldCache when the field is defined as non multivalue? 2. Add option to turn it off? > Overhaul ShapeFieldCache because its a memory pig > - > > Key: LUCENE-4698 > URL: https://issues.apache.org/jira/browse/LUCENE-4698 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial >Reporter: David Smiley > Attachments: solr_spatial_leak1.png > > > The org.apache.lucene.spatial.util.ShapeFieldCache* classes together > implement a spatial field cache for points, similar to FieldCache for other > fields. It supports a variable number of points per document, and it's > currently only used by the SpatialPrefixTree strategy because that's the only > strategy that supports a variable number of points per document. The other > spatial strategies use the FieldCache. The ShapeFieldCache has problems: > * It's a memory pig. Each point is stored as a Point object, instead of an > array of x & y coordinates. Furthermore, each Point is in an ArrayList that > exists for each Document. It's not done any differently when your spatial > data isn't multi-valued. > * The cache is not per-segment, it's per-IndexReader, thereby making it > un-friendly to NRT search. > * The cache entries don't self-expire optimally to free up memory. The cache > is simply stored in a WeakHashMap. The big cache > entries are only freed when the WeakHashMap is used and the JVM realizes the > IndexSearcher instance has been GC'ed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5138) requestHandler (qt) is not passing q when defined in solrconfig.xml
Bill Bell created SOLR-5138: --- Summary: requestHandler (qt) is not passing q when defined in solrconfig.xml Key: SOLR-5138 URL: https://issues.apache.org/jira/browse/SOLR-5138 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: OS: Linux 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux SOLR: 4.5-SNAPSHOT 1511470M - 2013-08-07 18:30:52 Reporter: Bill Bell Priority: Critical We have this qt defined: *:* lucene none json When called like this http://localhost:8080/solr/provider/select?echoParams=ALL&fq=pwid:xlkm7&wt=xml&qt=providerdetails the q does not seem to be recognized and no results are returned unless the q is explicitly set. In SOLR 3.6 the q is seen by the request handler. SOLR 4.5 (4.5-SNAPSHOT 1511470M - 2013-08-07 18:30:52) returns this - note that q=*:* is missing: 01ALLALLproviderdetailsxmlpwid:xlkm7 3.6.2 returns the following - note q=*:* is shown: 01ALL*:*xmlALLxmlproviderdetailspwid:xlkm7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3191) field exclusion from fl
[ https://issues.apache.org/jira/browse/SOLR-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13736056#comment-13736056 ] Bill Bell commented on SOLR-3191: - This is a very useful feature I have 80 fields and want to just eclude one large field... > field exclusion from fl > --- > > Key: SOLR-3191 > URL: https://issues.apache.org/jira/browse/SOLR-3191 > Project: Solr > Issue Type: Improvement >Reporter: Luca Cavanna >Priority: Minor > > I think it would be useful to add a way to exclude field from the Solr > response. If I have for example 100 stored fields and I want to return all of > them but one, it would be handy to list just the field I want to exclude > instead of the 99 fields for inclusion through fl. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2345) Extend geodist() to support MultiValued lat long field
[
https://issues.apache.org/jira/browse/SOLR-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732981#comment-13732981
]
Bill Bell commented on SOLR-2345:
-
Can you please apply this to branches/lucene_solr_4_4 with LUCENE-5118 as well?
> Extend geodist() to support MultiValued lat long field
> --
>
> Key: SOLR-2345
> URL: https://issues.apache.org/jira/browse/SOLR-2345
> Project: Solr
> Issue Type: New Feature
> Components: spatial
>Reporter: Bill Bell
>Assignee: David Smiley
> Fix For: 4.5, 5.0
>
> Attachments: SOLR-2345_geodist_refactor.patch,
> SOLR-2345_geodist_support_for_RPT.patch
>
>
> Extend geodist() and {!geofilt} to support a multiValued lat,long field
> without using geohash.
> sort=geodist() asc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4704) Easy parameter injection into new Spatial for Circles
[
https://issues.apache.org/jira/browse/SOLR-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732178#comment-13732178
]
Bill Bell commented on SOLR-4704:
-
IS this resolved?
WHat we want to do is set up a QT with a parameter for $pt in Circle() or
geodist(). Then we can just send:
pt=26,-80 and then use:
pt=26,-80&facet.query=
{! key=1}
store_geohash:%22Intersects(Circle($pt%20d=.01447))%22
Instead of:
Circle(26.012156,-80.311943%20d=.361846)
> Easy parameter injection into new Spatial for Circles
> -
>
> Key: SOLR-4704
> URL: https://issues.apache.org/jira/browse/SOLR-4704
> Project: Solr
> Issue Type: Bug
>Reporter: Bill Bell
>
> I would like to be able to inject one PT and use it in all queries. Not sure
> how to do that?
> This will be in the QT:
> http://hgsolr2devmstr:8080/solr/providersearch/select?rows=0&q=*:*&facet=true&facet.query={!
>
> key=.5}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.0072369))%22&facet.query={!
>
> key=1}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.01447))%22&facet.query={!
>
> key=5}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.0723))%22&facet.query={!
>
> key=10}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.1447))%22&{!
>
> key=25}facet.query=store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.361846))%22&facet.query={!
>
> key=50}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.72369))%22&facet.query={!
>
> key=100}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=1.447))%22
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4911) Small refactor to make max and min float return values quicker
[ https://issues.apache.org/jira/browse/SOLR-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701782#comment-13701782 ] Bill Bell commented on SOLR-4911: - There might be a bug. +if(valsArr.length == 0)return 0.0f; +float val = Float.POSITIVE_INFINITY; should it return Float.POSITIVE_INFINITY; ? +if (valsArr.length == 0) return 0.0f; +float val = Float.NEGATIVE_INFINITY; And this return Float.NEGATIVE_INFINITY; ? I know the original code always returned 0.0f but wou;dn't this set the floor or ceiling as 0.0f? > Small refactor to make max and min float return values quicker > -- > > Key: SOLR-4911 > URL: https://issues.apache.org/jira/browse/SOLR-4911 > Project: Solr > Issue Type: Improvement >Reporter: Yogi Valani >Assignee: Erick Erickson >Priority: Trivial > Labels: patch > Fix For: 5.0, 4.4 > > Attachments: SOLR-4911.patch > > > Refactored function 'func' in MaxFloatFunction.java and > MinFloatFunction.java. Removed if statement out of loop. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4738) Update to latest Jetty bug fix release, 8.1.10
[ https://issues.apache.org/jira/browse/SOLR-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701771#comment-13701771 ] Bill Bell commented on SOLR-4738: - Why not move to Jetty 9? > Update to latest Jetty bug fix release, 8.1.10 > -- > > Key: SOLR-4738 > URL: https://issues.apache.org/jira/browse/SOLR-4738 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 5.0, 4.4 > > Attachments: SOLR-4738.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701764#comment-13701764 ] Bill Bell commented on SOLR-4685: - Thoughts? We have been using this in production and it works like a charm. We also get better performance, since the patch skips over checking the field for correct JSON. > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell >Assignee: Erik Hatcher > Attachments: SOLR-4685.1.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4788) Multiple Entities DIH delta import: dataimporter.[entityName].last_index_time is empty
[
https://issues.apache.org/jira/browse/SOLR-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701762#comment-13701762
]
Bill Bell commented on SOLR-4788:
-
Can we get this into 4.4?
> Multiple Entities DIH delta import: dataimporter.[entityName].last_index_time
> is empty
> --
>
> Key: SOLR-4788
> URL: https://issues.apache.org/jira/browse/SOLR-4788
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.2, 4.3
> Environment: solr-spec
> 4.2.1.2013.03.26.08.26.55
> solr-impl
> 4.2.1 1461071 - mark - 2013-03-26 08:26:55
> lucene-spec
> 4.2.1
> lucene-impl
> 4.2.1 1461071 - mark - 2013-03-26 08:23:34
> OR
> solr-spec
> 4.3.0
> solr-impl
> 4.3.0 1477023 - simonw - 2013-04-29 15:10:12
> lucene-spec
> 4.3.0
> lucene-impl
> 4.3.0 1477023 - simonw - 2013-04-29 14:55:14
>Reporter: chakming wong
>Assignee: Shalin Shekhar Mangar
> Attachments: entitytest.patch, entitytest.patch, entitytest.patch,
> entitytest.patch, entitytest.patch, SOLR-4788.patch
>
>
> {code:title=conf/dataimport.properties|borderStyle=solid}entity1.last_index_time=2013-05-06
> 03\:02\:06
> last_index_time=2013-05-06 03\:05\:22
> entity2.last_index_time=2013-05-06 03\:03\:14
> entity3.last_index_time=2013-05-06 03\:05\:22
> {code}
> {code:title=conf/solrconfig.xml|borderStyle=solid} encoding="UTF-8" ?>
> ...
> class="org.apache.solr.handler.dataimport.DataImportHandler">
>
> dihconfig.xml
>
>
> ...
> {code}
> {code:title=conf/dihconfig.xml|borderStyle=solid} encoding="UTF-8" ?>
>
> type="JdbcDataSource" driver="com.mysql.jdbc.Driver"
> url="jdbc:mysql://*:*/*"
> user="*" password="*"/>
>
> query="SELECT * FROM table_a"
> deltaQuery="SELECT table_a_id FROM table_b WHERE
> last_modified > '${dataimporter.entity1.last_index_time}'"
> deltaImportQuery="SELECT * FROM table_a WHERE id =
> '${dataimporter.entity1.id}'"
> transformer="TemplateTransformer">
> ...
> ...
> ...
>
>
> ...
> ...
>
>
> ...
> ...
>
>
>
> {code}
> In above setup, *dataimporter.entity1.last_index_time* is *empty string* and
> cause the sql query having error
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701761#comment-13701761
]
Bill Bell commented on SOLR-2242:
-
The one use case (2 parts) that I want to make sure we are satisfying is:
. Ability to get total number of distinct terms in the facet.field.
For example, if facet.field=gender, I would expect the distinct to be 1 or 2
(Male/Female) depending on filters.
. For Sharding, Terrance might be the right approach, but is it accurate or an
approximation? For small sets sharding will work fine (< 100 results). For
example, if you were asking for distinct counts from 2 shards, and the shards
were setup for 20 states in one shard, and 30 in the other, I would expect
distinct states = 50. Will your solution do that?
Thanks - so happy this is moving forward. Not sure I understand the syntax from
Terrance yet... :)
> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
>Affects Versions: 4.0-ALPHA
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.4
>
> Attachments: SOLR-2242-3x_5_tests.patch, SOLR-2242-3x.patch,
> SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch,
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch,
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch, SOLR-2242-solr40-3.patch
>
>
> When returning facet.field= you will get a list of matches for
> distinct values. This is normal behavior. This patch tells you how many
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> Parameters:
> facet.numTerms or f..facet.numTerms = true (default is false) - turn
> on distinct counting of terms
> facet.field - the field to count the terms
> It creates a new section in the facet section...
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=true&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=false&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=true&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
>
>
> ...
>
>
> 14
>
>
> 14
>
>
>
>
>
> OR with no sharding-
>
> 14
>
> {code}
> Several people use this to get the group.field count (the # of groups).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4788) Multiple Entities DIH delta import: dataimporter.[entityName].last_index_time is empty
[
https://issues.apache.org/jira/browse/SOLR-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13699108#comment-13699108
]
Bill Bell commented on SOLR-4788:
-
We are also running into this issue. Not sure how it happens yet though.
> Multiple Entities DIH delta import: dataimporter.[entityName].last_index_time
> is empty
> --
>
> Key: SOLR-4788
> URL: https://issues.apache.org/jira/browse/SOLR-4788
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.2, 4.3
> Environment: solr-spec
> 4.2.1.2013.03.26.08.26.55
> solr-impl
> 4.2.1 1461071 - mark - 2013-03-26 08:26:55
> lucene-spec
> 4.2.1
> lucene-impl
> 4.2.1 1461071 - mark - 2013-03-26 08:23:34
> OR
> solr-spec
> 4.3.0
> solr-impl
> 4.3.0 1477023 - simonw - 2013-04-29 15:10:12
> lucene-spec
> 4.3.0
> lucene-impl
> 4.3.0 1477023 - simonw - 2013-04-29 14:55:14
>Reporter: chakming wong
>Assignee: Shalin Shekhar Mangar
> Attachments: entitytest.patch, entitytest.patch, entitytest.patch,
> entitytest.patch, entitytest.patch
>
>
> {code:title=conf/dataimport.properties|borderStyle=solid}entity1.last_index_time=2013-05-06
> 03\:02\:06
> last_index_time=2013-05-06 03\:05\:22
> entity2.last_index_time=2013-05-06 03\:03\:14
> entity3.last_index_time=2013-05-06 03\:05\:22
> {code}
> {code:title=conf/solrconfig.xml|borderStyle=solid} encoding="UTF-8" ?>
> ...
> class="org.apache.solr.handler.dataimport.DataImportHandler">
>
> dihconfig.xml
>
>
> ...
> {code}
> {code:title=conf/dihconfig.xml|borderStyle=solid} encoding="UTF-8" ?>
>
> type="JdbcDataSource" driver="com.mysql.jdbc.Driver"
> url="jdbc:mysql://*:*/*"
> user="*" password="*"/>
>
> query="SELECT * FROM table_a"
> deltaQuery="SELECT table_a_id FROM table_b WHERE
> last_modified > '${dataimporter.entity1.last_index_time}'"
> deltaImportQuery="SELECT * FROM table_a WHERE id =
> '${dataimporter.entity1.id}'"
> transformer="TemplateTransformer">
> ...
> ...
> ...
>
>
> ...
> ...
>
>
> ...
> ...
>
>
>
> {code}
> In above setup, *dataimporter.entity1.last_index_time* is *empty string* and
> cause the sql query having error
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661499#comment-13661499 ] Bill Bell commented on SOLR-4839: - Stable 9.0.3.v20130506 > Jetty 9 > --- > > Key: SOLR-4839 > URL: https://issues.apache.org/jira/browse/SOLR-4839 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell > > Implement Jetty 9 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4839) Jetty 9
Bill Bell created SOLR-4839: --- Summary: Jetty 9 Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Implement Jetty 9 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4788) Multiple Entities DIH delta import: dataimporter.[entityName].last_index_time is empty
[
https://issues.apache.org/jira/browse/SOLR-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661496#comment-13661496
]
Bill Bell commented on SOLR-4788:
-
Has someone fixed this? I am not seeing a patch.
> Multiple Entities DIH delta import: dataimporter.[entityName].last_index_time
> is empty
> --
>
> Key: SOLR-4788
> URL: https://issues.apache.org/jira/browse/SOLR-4788
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.2, 4.3
> Environment: solr-spec
> 4.2.1.2013.03.26.08.26.55
> solr-impl
> 4.2.1 1461071 - mark - 2013-03-26 08:26:55
> lucene-spec
> 4.2.1
> lucene-impl
> 4.2.1 1461071 - mark - 2013-03-26 08:23:34
> OR
> solr-spec
> 4.3.0
> solr-impl
> 4.3.0 1477023 - simonw - 2013-04-29 15:10:12
> lucene-spec
> 4.3.0
> lucene-impl
> 4.3.0 1477023 - simonw - 2013-04-29 14:55:14
>Reporter: chakming wong
>Assignee: Shalin Shekhar Mangar
>
> {code:title=conf/dataimport.properties|borderStyle=solid}entity1.last_index_time=2013-05-06
> 03\:02\:06
> last_index_time=2013-05-06 03\:05\:22
> entity2.last_index_time=2013-05-06 03\:03\:14
> entity3.last_index_time=2013-05-06 03\:05\:22
> {code}
> {code:title=conf/solrconfig.xml|borderStyle=solid} encoding="UTF-8" ?>
> ...
> class="org.apache.solr.handler.dataimport.DataImportHandler">
>
> dihconfig.xml
>
>
> ...
> {code}
> {code:title=conf/dihconfig.xml|borderStyle=solid} encoding="UTF-8" ?>
>
> type="JdbcDataSource" driver="com.mysql.jdbc.Driver"
> url="jdbc:mysql://*:*/*"
> user="*" password="*"/>
>
> query="SELECT * FROM table_a"
> deltaQuery="SELECT table_a_id FROM table_b WHERE
> last_modified > '${dataimporter.entity1.last_index_time}'"
> deltaImportQuery="SELECT * FROM table_a WHERE id =
> '${dataimporter.entity1.id}'"
> transformer="TemplateTransformer">
> ...
> ...
> ...
>
>
> ...
> ...
>
>
> ...
> ...
>
>
>
> {code}
> In above setup, *dataimporter.entity1.last_index_time* is *empty string* and
> cause the sql query having error
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4774) Solr support Lucene Facets
Bill Bell created SOLR-4774: --- Summary: Solr support Lucene Facets Key: SOLR-4774 URL: https://issues.apache.org/jira/browse/SOLR-4774 Project: Solr Issue Type: Bug Reporter: Bill Bell Since facets are now included in Lucene... 1. Solr schema taxonomy glue 2. Switch query results to use this glue with a new param like facet.lucene=true? Seems like a great enhancement ! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644287#comment-13644287
]
Bill Bell commented on SOLR-2242:
-
Yeah. This issue has stalled. To get it ready for release we just need to apply
the patch and run all unit tests.
Issues tend to stall when we don't have a commiter leading the work to get
done. If someone will step up I will commit to do the work. the last time I
made a push for this there was several approaches:
1. Change the facet formats (Yonik)
2. Change the parameter names and hide the fact that we are looping through all
(limit=-1).
3. Try to get the sharding working. Although I would contend that we can
release without sharding and add it later. Sharding - we can send the unique
terms and combine to get exact numbers, or we can separate and send (as it is
now). The former is much harder to do and could cause perf issues.
Thoughts? Maybe at the Lucene conference this can be discussed?
> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
>Affects Versions: 4.0-ALPHA
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.3
>
> Attachments: SOLR-2242-3x_5_tests.patch, SOLR-2242-3x.patch,
> SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch,
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch,
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch, SOLR-2242-solr40-3.patch
>
>
> When returning facet.field= you will get a list of matches for
> distinct values. This is normal behavior. This patch tells you how many
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> Parameters:
> facet.numTerms or f..facet.numTerms = true (default is false) - turn
> on distinct counting of terms
> facet.field - the field to count the terms
> It creates a new section in the facet section...
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=true&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=false&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=true&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
>
>
> ...
>
>
> 14
>
>
> 14
>
>
>
>
>
> OR with no sharding-
>
> 14
>
> {code}
> Several people use this to get the group.field count (the # of groups).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell reassigned SOLR-4685: --- Assignee: Erik Hatcher > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell >Assignee: Erik Hatcher > Attachments: SOLR-4685.1.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-4704) Easy parameter injection into new Spatial for Circles
[
https://issues.apache.org/jira/browse/SOLR-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell closed SOLR-4704.
---
Resolution: Duplicate
> Easy parameter injection into new Spatial for Circles
> -
>
> Key: SOLR-4704
> URL: https://issues.apache.org/jira/browse/SOLR-4704
> Project: Solr
> Issue Type: Bug
> Reporter: Bill Bell
>
> I would like to be able to inject one PT and use it in all queries. Not sure
> how to do that?
> This will be in the QT:
> http://hgsolr2devmstr:8080/solr/providersearch/select?rows=0&q=*:*&facet=true&facet.query={!
>
> key=.5}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.0072369))%22&facet.query={!
>
> key=1}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.01447))%22&facet.query={!
>
> key=5}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.0723))%22&facet.query={!
>
> key=10}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.1447))%22&{!
>
> key=25}facet.query=store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.361846))%22&facet.query={!
>
> key=50}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.72369))%22&facet.query={!
>
> key=100}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=1.447))%22
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13637587#comment-13637587 ] Bill Bell commented on SOLR-4685: - OK we ready to commit this? > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell > Attachments: SOLR-4685.1.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-4685: Attachment: (was: SOLR-4685.patch) > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell > Attachments: SOLR-4685.1.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-4685: Attachment: SOLR-4685.1.patch > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell > Attachments: SOLR-4685.1.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631537#comment-13631537 ] Bill Bell commented on SOLR-4685: - OK. I am uploading 2 test cases. 1. To test without escaping when using the new field. json.fsuffix=_json 2. To test the old way with escaping to make sure nothing was impacted. ant -Dtestcase=JSONWriterTest test > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell > Attachments: SOLR-4685.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4242) A better spatial query parser
[
https://issues.apache.org/jira/browse/SOLR-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631513#comment-13631513
]
Bill Bell commented on SOLR-4242:
-
spatialdist() ?
We really need this.
> A better spatial query parser
> -
>
> Key: SOLR-4242
> URL: https://issues.apache.org/jira/browse/SOLR-4242
> Project: Solr
> Issue Type: New Feature
> Components: query parsers
>Reporter: David Smiley
> Fix For: 4.3
>
>
> I've been thinking about how spatial support is exposed to Solr users.
> Presently there's the older Solr 3 stuff, most prominently seen via
> \{!geofilt} and \{!bbox} done by [~gsingers] (I think). and then there's the
> Solr 4 fields using a special syntax parsed by Lucene 4 spatial that looks
> like mygeofield:"Intersects(Circle(1 2 d=3))" What's inside the outer
> parenthesis is parsed by Spatial4j as a shape, and it has a special
> (non-standard) syntax for points, rects, and circles, and then there's WKT.
> I believe this scheme was devised by [~ryantxu].
> I'd like to devise something that is both comprehensive and is aligned with
> standards to the extent that it's prudent. The old Solr 3 stuff is not
> comprehensive and not standardized. The newer stuff is comprehensive but
> only a little based on standards. And I think it'd be nicer to implement it
> as a Solr query parser. I'll say more in the comments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4685) JSON response write modification to support RAW JSON
[ https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13629805#comment-13629805 ] Bill Bell commented on SOLR-4685: - Can somone give some feedback to me? This seems like a worthy addition. It is backwards compatible. No risk. > JSON response write modification to support RAW JSON > > > Key: SOLR-4685 > URL: https://issues.apache.org/jira/browse/SOLR-4685 > Project: Solr > Issue Type: Improvement > Reporter: Bill Bell > Attachments: SOLR-4685.patch > > > If the field ends with "_json" allow the field to return raw JSON. > For example the field, > office_json -- string > I already put into the field raw JSON already escaped. I want it to come with > no double quotes and not escaped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4704) Easy parameter injection into new Spatial for Circles
Bill Bell created SOLR-4704:
---
Summary: Easy parameter injection into new Spatial for Circles
Key: SOLR-4704
URL: https://issues.apache.org/jira/browse/SOLR-4704
Project: Solr
Issue Type: Bug
Reporter: Bill Bell
I would like to be able to inject one PT and use it in all queries. Not sure
how to do that?
This will be in the QT:
http://hgsolr2devmstr:8080/solr/providersearch/select?rows=0&q=*:*&facet=true&facet.query={!
key=.5}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.0072369))%22&facet.query={!
key=1}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.01447))%22&facet.query={!
key=5}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.0723))%22&facet.query={!
key=10}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.1447))%22&{!
key=25}facet.query=store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.361846))%22&facet.query={!
key=50}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=.72369))%22&facet.query={!
key=100}store_geohash:%22Intersects(Circle(26.012156,-80.311943%20d=1.447))%22
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4692) JSON Field transformer for DIH
[ https://issues.apache.org/jira/browse/SOLR-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626229#comment-13626229 ] Bill Bell commented on SOLR-4692: - In schema.xml > JSON Field transformer for DIH > -- > > Key: SOLR-4692 > URL: https://issues.apache.org/jira/browse/SOLR-4692 > Project: Solr > Issue Type: Bug > Reporter: Bill Bell > Attachments: JSONTransformer.java, JSONTransform.jar, xml.jar > > > This works in conjunction with SOLR-4685. > Takes an XML field from SQL / manually and adds it as a JSON field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
