db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3969) NPE if you declare a constraint on a generated column and omit the datatype
Date Wed, 03 Dec 2008 20:17:44 GMT

     [ 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:
>            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.

View raw message