|
If you were logged in you would be able to see more operations.
|
|
|
| Issue & fix info: |
Patch Available
|
| Resolution Date: |
04/Dec/08 09:02 PM
|
|
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 ) );
|
|
Description
|
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 ) );
|
Show » |
|
Bug
Resolved
Major
NPE if you declare a constraint on a generated column and omit the datatype
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.