[
https://issues.apache.org/jira/browse/DERBY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-3969:
---------------------------------
Attachment: derby-3969-01-aa-constraintsNoDatatype.diff
Attaching derby-3969-01-aa-constraintsNoDatatype.diff. This fixes the known
NPEs raised when declaring generated columns without datatypes but with
constraints. Will run tests.
1) For FOREIGN and PRIMARY keys, the NPEs occurred because datatypes were being
checked before the generation clauses were bound and the their datatypes
determined. The solution was to move the datatype checks after the generation
clauses are bound.
2) For CHECK constraints, the NPE occurred because the CHECK constraints were
bound against a dummy table which was constructed before the generation clauses
were bound. The solution was to update the datatypes in that table after
binding the generation clauses.
3) For NOT NULL constraints, the NPE was occurring in the parser. I chose not
to fix this problem. Instead, I raise an error if the user tries to declare a
NOT NULL constraint on a generated column which lacks an explicit datatype. I
decided not to tackle this case because I was up against a flaw in the Derby
data design: in Derby (as in many other RDBMSes), the NOT NULL constraint is
modelled as an aspect of the datatype. Getting this aspect of a datatype to
behave like a constraint looked like a tricky bit of brittle code which I did
not think was justified by the benefit provided. The workaround is to
explicitly declare the datatype of the generated column--this does not seem
like on onerous limitation to me. If someone thinks this syntactic sugar is
worth the effort, they are welcome to tackle this one.
Touches the following files:
M java/engine/org/apache/derby/loc/messages.xml
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
M java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
Now the parser raises an error if you try to declare an untyped generated
column as NOT NULL.
M java/engine/org/apache/derby/impl/sql/compile/TableElementList.java
A couple changes were made to this class: Moved the nullability-setting logic
out of the validation logic for constraints so that it could be called after
generation clauses were bound--this supports (1) above. Also updated the
corresponding datatype in the dummy table after binding a generation
clause--this supports (2) above.
M java/engine/org/apache/derby/impl/sql/compile/AlterTableNode.java
M java/engine/org/apache/derby/impl/sql/compile/CreateTableNode.java
Binding logic changed to call the new method in TableElementList which supports
(1).
M java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java
Introduced a new method for looking up a ResultColumn by name. The original
method set a referenced bit which broke the check that generation clauses can't
mention other generated columns.
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/GeneratedColumnsTest.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/GeneratedColumnsHelper.java
Added new tests.
> NPE if you declare a constraint on a generated column and omit the datatype
> ---------------------------------------------------------------------------
>
> Key: DERBY-3969
> URL: https://issues.apache.org/jira/browse/DERBY-3969
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.0.0
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-3969-01-aa-constraintsNoDatatype.diff
>
>
> The following script shows the problem for CHECK constraints. Other NPEs
> occur for PRIMARY, FOREIGN KEY, and NOT NULL constraints.
> drop table t_ccnd_1;
> -- raises a null pointer exception
> create table t_ccnd_1( a int, b generated always as ( -a ) check ( b < 0 ) );
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
