[
https://issues.apache.org/jira/browse/KUDU-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KUDU-2280:
------------------------------
Description:
When creating a table the schema data is used to check that a default value is
of the right size and type. This is possible because the column schema is
available and checked via {{KuduValue::Data->CheckTypeAndGetPointer}} in
{{KuduColumnSpec::ToColumnSchema}}.
When altering a table {{KuduValue::Data->GetSlice()}} is used instead because
we don't have the column schema information available. The Slice is then added
to the alter table request.
When this request is received server side, we can only check the size (if we
know the expected size) to validate the correct information was sent and cast
it to the correct value via {{ColumnSchema::ApplyDelta}}.
For some examples I can set a DOUBLE type default on an INT64 column, or a
FLOAT type default on an INT32 column. With the current size check logic (
{{col_delta.default_value->size() < type_info()->size()}} ) you can technically
set any type >= your target type.
An additional issue is that {{KuduValue::FromInt}} treats all integers as
int64_t values when calling {{KuduValue::Data->GetSlice()}}. This should mean
we can't alter the default value of any integer columns smaller than INT64
because the data size is too large once received by the server. This "size"
problem affects the ability to support decimal defaults too.
example (where column "default" is an INT32 column):
{noformat}
table_alterer->AlterColumn("default")->Default(KuduValue::FromInt(12345));{noformat}
However when quickly testing I didn't get the unusual behavior I expected, but
instead found that INT64 values were being allowed into INT32 columns but then
gave the wrong result on read. More investigation here is definitely needed.
To solve this we could require the expected column DataType to be passed along
with the request so that the server can validate the expected column, size, and
coerce the values smaller if needed/possible.
was:
When creating a table the schema data is used to check that a default value is
of the right size and type. This is possible because the column schema is
available and checked via {{KuduValue::Data->CheckTypeAndGetPointer}} in
{{KuduColumnSpec::ToColumnSchema}}.
When altering a table {{KuduValue::Data->GetSlice()}} is used instead because
we don't have the column schema information available. The Slice is then added
to the alter table request.
When this request is received server side, we can only check the size (if we
know the expected size) to validate the correct information was sent and cast
it to the correct value via {{ColumnSchema::ApplyDelta}}.
For some examples I can set a DOUBLE type default on an INT64 column, or a
FLOAT type default on an INT32 column. With the current size check logic (
{{col_delta.default_value->size() < type_info()->size()}} ) you can technically
set any type smaller than your target type.
An additional issue is that {{KuduValue::FromInt}} treats all integers as
int64_t values when calling {{KuduValue::Data->GetSlice()}}. This should mean
we can't alter the default value of any integer columns smaller than INT64
because the data size is too large once received by the server. This "size"
problem affects the ability to support decimal defaults too.
example (where column "default" is an INT32 column):
{noformat}
table_alterer->AlterColumn("default")->Default(KuduValue::FromInt(12345));{noformat}
However when quickly testing I didn't get the unusual behavior I expected, but
instead found that INT64 values were being allowed into INT32 columns but then
gave the wrong result on read. More investigation here is definitely needed.
To solve this we could require the expected column DataType to be passed along
with the request so that the server can validate the expected column, size, and
coerce the values smaller if needed/possible.
> Altering the column default isn't "type safe"
> ---------------------------------------------
>
> Key: KUDU-2280
> URL: https://issues.apache.org/jira/browse/KUDU-2280
> Project: Kudu
> Issue Type: Bug
> Components: client
> Affects Versions: 1.4.0
> Reporter: Grant Henke
> Priority: Major
> Labels: usability
>
> When creating a table the schema data is used to check that a default value
> is of the right size and type. This is possible because the column schema is
> available and checked via {{KuduValue::Data->CheckTypeAndGetPointer}} in
> {{KuduColumnSpec::ToColumnSchema}}.
> When altering a table {{KuduValue::Data->GetSlice()}} is used instead because
> we don't have the column schema information available. The Slice is then
> added to the alter table request.
> When this request is received server side, we can only check the size (if we
> know the expected size) to validate the correct information was sent and cast
> it to the correct value via {{ColumnSchema::ApplyDelta}}.
> For some examples I can set a DOUBLE type default on an INT64 column, or a
> FLOAT type default on an INT32 column. With the current size check logic (
> {{col_delta.default_value->size() < type_info()->size()}} ) you can
> technically set any type >= your target type.
> An additional issue is that {{KuduValue::FromInt}} treats all integers as
> int64_t values when calling {{KuduValue::Data->GetSlice()}}. This should mean
> we can't alter the default value of any integer columns smaller than INT64
> because the data size is too large once received by the server. This "size"
> problem affects the ability to support decimal defaults too.
> example (where column "default" is an INT32 column):
> {noformat}
> table_alterer->AlterColumn("default")->Default(KuduValue::FromInt(12345));{noformat}
> However when quickly testing I didn't get the unusual behavior I expected,
> but instead found that INT64 values were being allowed into INT32 columns but
> then gave the wrong result on read. More investigation here is definitely
> needed.
> To solve this we could require the expected column DataType to be passed
> along with the request so that the server can validate the expected column,
> size, and coerce the values smaller if needed/possible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
