[jira] [Updated] (IGNITE-20478) Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
[
https://issues.apache.org/jira/browse/IGNITE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-20478:
Fix Version/s: 3.0.0-beta2
> Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
>
>
> Key: IGNITE-20478
> URL: https://issues.apache.org/jira/browse/IGNITE-20478
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when scanning an index, we set a special value called
> "UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches
> the bound (more details in IGNITE-16443).
> To be able to complete the transition to using a binary tuple, we need to
> rework this approach and try to avoid storing non-conforming schema values in
> row.
> Currently, this placeholder sets to row when the search bound is open (that
> is, when the RexNode is null in the list when creating a scalar).
> {{ExpressionFactoryImpl#expandBounds}} needs to be reworked and there should
> be no open bounds (see {{ExpressionFactoryImpl#compile}} all nodes elements
> must not be null).
> After reworking {{expandBounds}} the {{searchRow}} that comes to
> {{RowConverter#toBinaryTuplePrefix}} should already contain a prefix only.
> The code {{ExpressionFactoryImpl#comparator}} that uses this placeholder does
> not appear to be executing and can be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20478) Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
[
https://issues.apache.org/jira/browse/IGNITE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20478:
--
Description:
Currently, when scanning an index, we set a special value called
"UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches the
bound (more details in IGNITE-16443).
To be able to complete the transition to using a binary tuple, we need to
rework this approach and try to avoid storing non-conforming schema values in
row.
Currently, this placeholder sets to row when the search bound is open (that is,
when the RexNode is null in the list when creating a scalar).
{{ExpressionFactoryImpl#expandBounds}} needs to be reworked and there should be
no open bounds (see {{ExpressionFactoryImpl#compile}} all nodes elements must
not be null).
After reworking {{expandBounds}} the {{searchRow}} that comes to
{{RowConverter#toBinaryTuplePrefix}} should already contain a prefix only.
The code {{ExpressionFactoryImpl#comparator}} that uses this placeholder does
not appear to be executing and can be removed.
was:
Currently, when scanning an index, we set a special value called
"UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches the
bound (more details in IGNITE-16443).
To be able to complete the transition to using a binary tuple, we need to
rework this approach and try to avoid storing non-conforming schema values in
row.
Currently, this placeholder sets to row when the search bound is open (that is,
when the RexNode is null in the list when creating a scalar).
{{ExpressionFactoryImpl#expandBounds}} needs to be reworked and there should be
no open bounds (see {{ExpressionFactoryImpl#compile}} all nodes elements must
not be null).
After reworking {{expandBounds}} the {{searchRow}} that comes to
{{RowConverter#toBinaryTuplePrefix}} should already contain a prefix only.
In {{ExpressionFactoryImpl#comparator}} this placeholder does not seem to be
used and this code can be removed.
> Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
>
>
> Key: IGNITE-20478
> URL: https://issues.apache.org/jira/browse/IGNITE-20478
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently, when scanning an index, we set a special value called
> "UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches
> the bound (more details in IGNITE-16443).
> To be able to complete the transition to using a binary tuple, we need to
> rework this approach and try to avoid storing non-conforming schema values in
> row.
> Currently, this placeholder sets to row when the search bound is open (that
> is, when the RexNode is null in the list when creating a scalar).
> {{ExpressionFactoryImpl#expandBounds}} needs to be reworked and there should
> be no open bounds (see {{ExpressionFactoryImpl#compile}} all nodes elements
> must not be null).
> After reworking {{expandBounds}} the {{searchRow}} that comes to
> {{RowConverter#toBinaryTuplePrefix}} should already contain a prefix only.
> The code {{ExpressionFactoryImpl#comparator}} that uses this placeholder does
> not appear to be executing and can be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20478) Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
[
https://issues.apache.org/jira/browse/IGNITE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20478:
--
Description:
Currently, when scanning an index, we set a special value called
"UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches the
bound (more details in IGNITE-16443).
To be able to complete the transition to using a binary tuple, we need to
rework this approach and try to avoid storing non-conforming schema values in
row.
Currently, this placeholder is set to row when the search bound is open (that
is, when the RexNode is null in the list when creating a scalar).
{{ExpressionFactoryImpl#expandBounds}} needs to be reworked and there should be
no open bounds (see {{ExpressionFactoryImpl#compile}} all nodes elements must
not be null).
After reworking {{expandBounds}} the {{searchRow}} that comes to
{{RowConverter#toBinaryTuplePrefix}} should already contain a prefix only.
In {{ExpressionFactoryImpl#comparator}} this placeholder does not seem to be
used and this code can be removed.
was:
Currently, when scanning an index, we set a special value called
"UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches the
bound (more details in IGNITE-16443).
To be able to complete the transition to using a binary tuple, we need to
rework this approach and try to avoid storing non-conforming schema values in
row.
> Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
>
>
> Key: IGNITE-20478
> URL: https://issues.apache.org/jira/browse/IGNITE-20478
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently, when scanning an index, we set a special value called
> "UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches
> the bound (more details in IGNITE-16443).
> To be able to complete the transition to using a binary tuple, we need to
> rework this approach and try to avoid storing non-conforming schema values in
> row.
> Currently, this placeholder is set to row when the search bound is open (that
> is, when the RexNode is null in the list when creating a scalar).
> {{ExpressionFactoryImpl#expandBounds}} needs to be reworked and there should
> be no open bounds (see {{ExpressionFactoryImpl#compile}} all nodes elements
> must not be null).
> After reworking {{expandBounds}} the {{searchRow}} that comes to
> {{RowConverter#toBinaryTuplePrefix}} should already contain a prefix only.
> In {{ExpressionFactoryImpl#comparator}} this placeholder does not seem to be
> used and this code can be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20478) Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
[
https://issues.apache.org/jira/browse/IGNITE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20478:
--
Description:
Currently, when scanning an index, we set a special value called
"UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches the
bound (more details in IGNITE-16443).
To be able to complete the transition to using a binary tuple, we need to
rework this approach and try to avoid storing non-conforming schema values in
row.
Currently, this placeholder sets to row when the search bound is open (that is,
when the RexNode is null in the list when creating a scalar).
{{ExpressionFactoryImpl#expandBounds}} needs to be reworked and there should be
no open bounds (see {{ExpressionFactoryImpl#compile}} all nodes elements must
not be null).
After reworking {{expandBounds}} the {{searchRow}} that comes to
{{RowConverter#toBinaryTuplePrefix}} should already contain a prefix only.
In {{ExpressionFactoryImpl#comparator}} this placeholder does not seem to be
used and this code can be removed.
was:
Currently, when scanning an index, we set a special value called
"UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches the
bound (more details in IGNITE-16443).
To be able to complete the transition to using a binary tuple, we need to
rework this approach and try to avoid storing non-conforming schema values in
row.
Currently, this placeholder is set to row when the search bound is open (that
is, when the RexNode is null in the list when creating a scalar).
{{ExpressionFactoryImpl#expandBounds}} needs to be reworked and there should be
no open bounds (see {{ExpressionFactoryImpl#compile}} all nodes elements must
not be null).
After reworking {{expandBounds}} the {{searchRow}} that comes to
{{RowConverter#toBinaryTuplePrefix}} should already contain a prefix only.
In {{ExpressionFactoryImpl#comparator}} this placeholder does not seem to be
used and this code can be removed.
> Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
>
>
> Key: IGNITE-20478
> URL: https://issues.apache.org/jira/browse/IGNITE-20478
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently, when scanning an index, we set a special value called
> "UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches
> the bound (more details in IGNITE-16443).
> To be able to complete the transition to using a binary tuple, we need to
> rework this approach and try to avoid storing non-conforming schema values in
> row.
> Currently, this placeholder sets to row when the search bound is open (that
> is, when the RexNode is null in the list when creating a scalar).
> {{ExpressionFactoryImpl#expandBounds}} needs to be reworked and there should
> be no open bounds (see {{ExpressionFactoryImpl#compile}} all nodes elements
> must not be null).
> After reworking {{expandBounds}} the {{searchRow}} that comes to
> {{RowConverter#toBinaryTuplePrefix}} should already contain a prefix only.
> In {{ExpressionFactoryImpl#comparator}} this placeholder does not seem to be
> used and this code can be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20478) Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
[ https://issues.apache.org/jira/browse/IGNITE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-20478: -- Summary: Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row. (was: Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER value in row.) > Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row. > > > Key: IGNITE-20478 > URL: https://issues.apache.org/jira/browse/IGNITE-20478 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Currently, when scanning an index, we set a special value called > "UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches > the bound (more details in IGNITE-16443). > To be able to complete the transition to using a binary tuple, we need to > rework this approach and try to avoid storing non-conforming schema values in > row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
