[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871679#comment-16871679
]
Jason Gerlowski commented on SOLR-13318:
Thanks for bringing this up again.
It probably still makes sense to backport. I'm not sure what the odds of a
7.7.3 release are, but the effort required to backport this is low, and if one
occurs, it would be nice to offer this fix to people in it.
I can put it on my todo list for this week, and will make sure I follow up this
time.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871207#comment-16871207
]
Munendra S N commented on SOLR-13318:
-
[~gerlowskija]
I also lost track of it. 7.7.2 is already released. Should we still backport
it to 7.7x so that if there is any release for 7.7x this could be included or
just resolve as it is fixed in 8.1?
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833752#comment-16833752
]
Jason Gerlowski commented on SOLR-13318:
Yes, I'd like to backport to 7.7.2 but ran out of time last night. If I have
time after work today I'm still aiming for 7.7.2, as long as there's not an RC
or a freeze before then.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833740#comment-16833740
]
Munendra S N commented on SOLR-13318:
-
Makes sense. Also, is there a plan to backport this to 7.7x as there is plan to
release 7.7.2??
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833710#comment-16833710
]
Jason Gerlowski commented on SOLR-13318:
bq. Would this be okay from a user's perspective?
I agree it's not great, but hopefully its good enough. The approach that I
took here causes anyone currently using BucketBasedJsonFacet to potentially
update their code twice. That's not ideal. You're right. But I also didn't
want new users coming in to 9.0 to see method names that were inconsistent with
the rest of that group of classes (e.g. "What does that "count" suffix mean on
{{getNumBucketsCount}}? Nothing else has that, maybe it doesn't mean what I
think"). Both options are non-ideal, but we have to choose one.
I tried to choose the option that would affect the fewest users. As of 7.x and
8.0, BucketBasedJsonFacet throws an undeclared exception when used with any
multi-shard collection. This is a huge problem, and makes the methods arguably
unusable. Because of this, there are probably very few BBJF users. So I opted
to cause those few users a bit of extra work, in favor of having a more
consistent interface for the users coming on in 9.x, now that the class is
safer.
So anyway, there are negative aspects of this approach, but hopefully
outweighed or mitigated by other things.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833539#comment-16833539
]
Munendra S N commented on SOLR-13318:
-
[~gerlowskija]
Thanks for merging this
In branch_8x and branch_8_1, new methods are introduced and old methods are
deprecated. In the master, old methods are changed to return long instead of
int and new methods are not added
So, any one using new methods after 8.1 release, again have to make changes to
use different methods in 9.0. Would this okay from user perspective?
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833520#comment-16833520
]
ASF subversion and git services commented on SOLR-13318:
Commit 538b450236367907b4ab75852ca6d44032ac670b in lucene-solr's branch
refs/heads/branch_8_1 from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=538b450 ]
SOLR-13318: Fix casting issues in BucketBasedJsonFacet
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833518#comment-16833518
]
ASF subversion and git services commented on SOLR-13318:
Commit 919b0854448174c626c9ffc7c11770ae2477b210 in lucene-solr's branch
refs/heads/branch_8x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=919b085 ]
SOLR-13318: Fix casting issues in BucketBasedJsonFacet
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833516#comment-16833516
]
ASF subversion and git services commented on SOLR-13318:
Commit 4309c6eca474e41811fe8fbbee10b501dfe60f93 in lucene-solr's branch
refs/heads/master from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4309c6e ]
SOLR-13318: Fix casting issues in BucketBasedJsonFacet
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829170#comment-16829170
]
Jason Gerlowski commented on SOLR-13318:
Hi Munendra, thanks for the reminder. I looked at the patches when you
uploaded them, but haven't found time to test in more detail. I promise to get
this in for 8.1 though.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16828941#comment-16828941
]
Munendra S N commented on SOLR-13318:
-
[~gerlowskija]
Hi,
Did you get chance to look into the latest patch? It would be great if this
gets resolved in 8.1(based on Dev-mail group, branch would be cut on 30th
April). Thanks again
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822405#comment-16822405
]
Munendra S N commented on SOLR-13318:
-
[^SOLR-13318.patch] [^SOLR-13318-branch_8x.patch]
[~gerlowskija]
I have attached separate patches for master and branch_8x. I have introduced
new methods and deprecated old ones in branch_8x(as suggested above). With the
master's patch, I have removed deprecated methods.
Please suggest if anything else needs to be changed.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812026#comment-16812026
]
Jason Gerlowski commented on SOLR-13318:
Thanks for the patch Munendra. I agree with the comments you left in the patch
- we'll have to change the types of our instance vars where you pointed them
out, as well as some method return types.
You're also right that changing those return types would run afoul of our
back-compat policy. We've got a few options:
1. Only fix this in master, and requires users wait until 9.0 for the fix.
2. Keep the int-returning methods and leave their signatures as-is, while
introducing near-duplicate methods that return the correct types. Deprecate
the int-returning versions with references to these new methods.
3. Make a special request on the dev-list to exempt this change from our
back-compat policy. I think there's an "ok" argument for doing that here...our
backcompat policy is intended to help us serve our users. Slavishly
maintaining backcompat and keeping the buggy versions of these methods around
meets the letter of that law, but totally fails to meet the spirit. We're not
doing our users any favors by keeping these methods around.
So to answer your question ("Should I create different patches"), I'm not
entirely decided. I might appeal to the dev-list to see if anyone cares in
this case. But most likely I'll pursue option 2. In that case, I'll build off
of your patch and introduce the duplicate methods and deprecation warnings.
I'll try to something ready on this sometime this week.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811897#comment-16811897
]
Munendra S N commented on SOLR-13318:
-
[~gerlowskija]
[^SOLR-13318.patch]
This handles count being int in standalone and long in distrib mode but there
are other cases where long is returned in distrib mode. I have added comment in
those cases.
Changing them to long would break compatibility. So, if those changes are made
then, it could be only committed to master. Let me know how to proceed on
this(Should I create different patches for master and branch_8x?)
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
