[
https://issues.apache.org/jira/browse/DERBY-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708054#action_12708054
]
Bryan Pendleton commented on DERBY-4187:
----------------------------------------
Hi Eranda,
I think this is interesting. I think that perhaps this was a mistake in the
current altertable.sql test.
The sequence of operations is:
1) Prepare ("select * from t2")
2) Execute prepared statement, sees only column c1
3) alter table t2 add column c2
4) Execute prepared statement, STILL sees only column c1, though the IJ version
saw both c1 AND c2
I think this is OK behavior. I'm not really sure why there is a behavior
difference
between the IJ-based test and the pure JDBC Junit test, but I think it's
acceptable
for Derby to have either behavior.
Does anybody else have a theory as to why we see this behavior change when we
convert this test from an IJ script to a JUnit JDBC test?
For the time being, I think you should leave AlterTableTest checking for JUST
column c1,
put a comment into the test indicating that when this test is run in IJ, the
behavior is
different, and let's move on to resolve any other problems in the test.
> Convert altertable.sql to JUnit
> -------------------------------
>
> Key: DERBY-4187
> URL: https://issues.apache.org/jira/browse/DERBY-4187
> Project: Derby
> Issue Type: Test
> Components: Test
> Affects Versions: 10.4.2.1
> Reporter: Eranda Sooriyabandara
> Priority: Minor
> Fix For: 10.5.1.2
>
> Attachments: AlterTable.diff, AlterTable.java, AlterTableTest.diff,
> AlterTableTest.diff, AlterTableTest.diff, AlterTableTest.java
>
> Original Estimate: 486.08h
> Remaining Estimate: 486.08h
>
> Converting altertable.sql harness test to JUnit
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
