[jira] [Assigned] (SPARK-39839) Handle special case of null variable-length Decimal with non-zero offsetAndSize in UnsafeRow structural integrity check
[
https://issues.apache.org/jira/browse/SPARK-39839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Apache Spark reassigned SPARK-39839:
Assignee: Apache Spark
> Handle special case of null variable-length Decimal with non-zero
> offsetAndSize in UnsafeRow structural integrity check
> ---
>
> Key: SPARK-39839
> URL: https://issues.apache.org/jira/browse/SPARK-39839
> Project: Spark
> Issue Type: Bug
> Components: SQL
>Affects Versions: 3.1.0, 3.2.0, 3.3.0
>Reporter: Kris Mok
>Assignee: Apache Spark
>Priority: Major
>
> The {{UnsafeRow}} structural integrity check in
> {{UnsafeRowUtils.validateStructuralIntegrity}} is added in Spark 3.1.0. It’s
> supposed to validate that a given {{UnsafeRow}} conforms to the format that
> the {{UnsafeRowWriter}} would have produced.
> Currently the check expects all fields that are marked as null should also
> have its field (i.e. the fixed-length part) set to all zeros. It needs to be
> updated to handle a special case for variable-length {{{}Decimal{}}}s, where
> the {{UnsafeRowWriter}} may mark a field as null but also leave the
> fixed-length part of the field as {{OffsetAndSize(offset=current_offset,
> size=0)}}. This may happen when the {{Decimal}} being written is either a
> real {{null}} or has overflowed the specified precision.
> Logic in {{UnsafeRowWriter}}:
> in general:
> {code:scala}
> public void setNullAt(int ordinal) {
> BitSetMethods.set(getBuffer(), startingOffset, ordinal); // set null bit
> write(ordinal, 0L); // also zero out
> the fixed-length field
> } {code}
> special case for {{DecimalType}}:
> {code:scala}
> // Make sure Decimal object has the same scale as DecimalType.
> // Note that we may pass in null Decimal object to set null for it.
> if (input == null || !input.changePrecision(precision, scale)) {
> BitSetMethods.set(getBuffer(), startingOffset, ordinal); // set null
> bit
> // keep the offset for future update
> setOffsetAndSize(ordinal, 0); // doesn't
> zero out the fixed-length field
> } {code}
> The special case is introduced to allow all {{DecimalType}}s (including both
> fixed-length and variable-length ones) to be mutable – thus need to leave
> space for the variable-length field even if it’s currently null.
> Note that this special case in {{UnsafeRowWriter}} has been there since Spark
> 1.6.0, where as the integrity check was added in Spark 3.1.0. The check was
> originally added for Structured Streaming’s checkpoint evolution validation,
> so that a newer version of Spark can check whether or not an older checkpoint
> file for Structured Streaming queries can be supported, and/or if the
> contents of the checkpoint file is corrupted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
[jira] [Assigned] (SPARK-39839) Handle special case of null variable-length Decimal with non-zero offsetAndSize in UnsafeRow structural integrity check
[
https://issues.apache.org/jira/browse/SPARK-39839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Apache Spark reassigned SPARK-39839:
Assignee: (was: Apache Spark)
> Handle special case of null variable-length Decimal with non-zero
> offsetAndSize in UnsafeRow structural integrity check
> ---
>
> Key: SPARK-39839
> URL: https://issues.apache.org/jira/browse/SPARK-39839
> Project: Spark
> Issue Type: Bug
> Components: SQL
>Affects Versions: 3.1.0, 3.2.0, 3.3.0
>Reporter: Kris Mok
>Priority: Major
>
> The {{UnsafeRow}} structural integrity check in
> {{UnsafeRowUtils.validateStructuralIntegrity}} is added in Spark 3.1.0. It’s
> supposed to validate that a given {{UnsafeRow}} conforms to the format that
> the {{UnsafeRowWriter}} would have produced.
> Currently the check expects all fields that are marked as null should also
> have its field (i.e. the fixed-length part) set to all zeros. It needs to be
> updated to handle a special case for variable-length {{{}Decimal{}}}s, where
> the {{UnsafeRowWriter}} may mark a field as null but also leave the
> fixed-length part of the field as {{OffsetAndSize(offset=current_offset,
> size=0)}}. This may happen when the {{Decimal}} being written is either a
> real {{null}} or has overflowed the specified precision.
> Logic in {{UnsafeRowWriter}}:
> in general:
> {code:scala}
> public void setNullAt(int ordinal) {
> BitSetMethods.set(getBuffer(), startingOffset, ordinal); // set null bit
> write(ordinal, 0L); // also zero out
> the fixed-length field
> } {code}
> special case for {{DecimalType}}:
> {code:scala}
> // Make sure Decimal object has the same scale as DecimalType.
> // Note that we may pass in null Decimal object to set null for it.
> if (input == null || !input.changePrecision(precision, scale)) {
> BitSetMethods.set(getBuffer(), startingOffset, ordinal); // set null
> bit
> // keep the offset for future update
> setOffsetAndSize(ordinal, 0); // doesn't
> zero out the fixed-length field
> } {code}
> The special case is introduced to allow all {{DecimalType}}s (including both
> fixed-length and variable-length ones) to be mutable – thus need to leave
> space for the variable-length field even if it’s currently null.
> Note that this special case in {{UnsafeRowWriter}} has been there since Spark
> 1.6.0, where as the integrity check was added in Spark 3.1.0. The check was
> originally added for Structured Streaming’s checkpoint evolution validation,
> so that a newer version of Spark can check whether or not an older checkpoint
> file for Structured Streaming queries can be supported, and/or if the
> contents of the checkpoint file is corrupted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
[jira] [Assigned] (SPARK-39839) Handle special case of null variable-length Decimal with non-zero offsetAndSize in UnsafeRow structural integrity check
[
https://issues.apache.org/jira/browse/SPARK-39839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jungtaek Lim reassigned SPARK-39839:
Assignee: Kris Mok
> Handle special case of null variable-length Decimal with non-zero
> offsetAndSize in UnsafeRow structural integrity check
> ---
>
> Key: SPARK-39839
> URL: https://issues.apache.org/jira/browse/SPARK-39839
> Project: Spark
> Issue Type: Bug
> Components: SQL
>Affects Versions: 3.1.0, 3.2.0, 3.3.0
>Reporter: Kris Mok
>Assignee: Kris Mok
>Priority: Major
>
> The {{UnsafeRow}} structural integrity check in
> {{UnsafeRowUtils.validateStructuralIntegrity}} is added in Spark 3.1.0. It’s
> supposed to validate that a given {{UnsafeRow}} conforms to the format that
> the {{UnsafeRowWriter}} would have produced.
> Currently the check expects all fields that are marked as null should also
> have its field (i.e. the fixed-length part) set to all zeros. It needs to be
> updated to handle a special case for variable-length {{{}Decimal{}}}s, where
> the {{UnsafeRowWriter}} may mark a field as null but also leave the
> fixed-length part of the field as {{OffsetAndSize(offset=current_offset,
> size=0)}}. This may happen when the {{Decimal}} being written is either a
> real {{null}} or has overflowed the specified precision.
> Logic in {{UnsafeRowWriter}}:
> in general:
> {code:scala}
> public void setNullAt(int ordinal) {
> BitSetMethods.set(getBuffer(), startingOffset, ordinal); // set null bit
> write(ordinal, 0L); // also zero out
> the fixed-length field
> } {code}
> special case for {{DecimalType}}:
> {code:scala}
> // Make sure Decimal object has the same scale as DecimalType.
> // Note that we may pass in null Decimal object to set null for it.
> if (input == null || !input.changePrecision(precision, scale)) {
> BitSetMethods.set(getBuffer(), startingOffset, ordinal); // set null
> bit
> // keep the offset for future update
> setOffsetAndSize(ordinal, 0); // doesn't
> zero out the fixed-length field
> } {code}
> The special case is introduced to allow all {{DecimalType}}s (including both
> fixed-length and variable-length ones) to be mutable – thus need to leave
> space for the variable-length field even if it’s currently null.
> Note that this special case in {{UnsafeRowWriter}} has been there since Spark
> 1.6.0, where as the integrity check was added in Spark 3.1.0. The check was
> originally added for Structured Streaming’s checkpoint evolution validation,
> so that a newer version of Spark can check whether or not an older checkpoint
> file for Structured Streaming queries can be supported, and/or if the
> contents of the checkpoint file is corrupted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
