[
https://issues.apache.org/jira/browse/DERBY-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6075:
--------------------------------------
Attachment: d6075-16a-negative-test.diff
Thanks for pointing me to NullsTest, Bryan. That test contains lots of negative
test cases to verify that explicit nullability cannot be used in combination
with explicit NOT NULL or PRIMARY KEY. However, there is no test case to verify
that explicit nullability alone is disallowed.
I guess this means declaring a column explicitly nullable used to be allowed in
some distant past, and that the test cases in NullsTest were written back then.
Attaching d6075-16a-negative-test.diff which adds negative test cases to verify
that
create table a(a1 int null)
and
alter table a add column a3 int null
fail with syntax errors.
The new negative test cases pass both with and without the patches that remove
the dead code from sqlgrammar.
Committed the 16a patch to trunk, revision 1455992.
> Use modern collections in impl/sql/compile
> ------------------------------------------
>
> Key: DERBY-6075
> URL: https://issues.apache.org/jira/browse/DERBY-6075
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.10.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d6075-10a-aggregate-vectors.diff,
> d6075-11a-remaining-vectors.diff, d6075-12a-stack.diff,
> d6075-13a-unused-properties.diff, d6075-14a-dead-syntax.diff,
> d6075-15a-sqlgrammar-vectors.diff, d6075-16a-negative-test.diff,
> d6075-1a-CollectNodesVisitor.diff, d6075-2a-bindExpression.diff,
> d6075-3a-javadoc.diff, d6075-4a-parameterList.diff, d6075-5a-ordering.diff,
> d6075-6a-DMLModStatementNode.diff, d6075-7a-more-signatures.diff,
> d6075-8a-local-hashtables.diff, d6075-9a-hashtable-fields.diff
>
>
> The code in the org.apache.derby.impl.sql.compile package predates the Java
> Collections Framework and uses old-style collections like java.util.Vector
> and java.util.Hashtable. Since the old-style collection classes are used in
> many method signatures, it's difficult to use modern collection classes when
> adding new code.
> I suggest we switch to using interfaces (like java.util.List and
> java.util.Map) instead of specific classes in the signatures, so that we have
> more flexibility in choosing the right collection class for the job.
> Only changing the signatures would allow us to continue using Vector and
> Hashtable, since they implement the interfaces. However, I think it would be
> good to switch to ArrayList and HashMap in a second step. The instances in
> impl/sql/compile are not shared between threads, so we don't need the
> synchronization provided by the old-style classes. Switching to
> unsynchronized classes may make compilation slightly faster.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
