[
https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-64:
---------------------
Derby Info: (was: [Patch Available])
Thank you for the latest patch, James. I ran derbyall on Red Hat Linux as a
sanity check and then committed the patch to the 10.3 trunk with svn revision
#495750.
I noticed that in the "suite()" method of the JUnit test you use:
+ suite.addTestSuite(CreateTableFromQueryTest.class);
instead of calling the default JUnit decorator, i.e.:
- suite.addTestSuite(CreateTableFromQueryTest.class);
+ suite.addTest(TestConfiguration.defaultSuite(
+ CreateTableFromQueryTest.class));
The latter ensures that the test runs in both embedded mode and client/server
mode, whereas the former (the patch as committed) only runs the test in
embedded mode. I think the general approach has been to try to run JUnit tests
in both modes (by using the "defaultSuite()" method shown above) unless there
is a specific reason to only run the test in one mode. To see what would
happen I made the above change and ran the new CreateTableFromQueryTest in both
modes without any problems.
This isn't a strict requirement, though, so I went ahead and committed the
patch as it was. If you agree that this makes sense and you would like to
change the test to use "defaultSuite()", you can post another follow-up patch
with just that change and I'll gladly commit it.
Also: I don't think anyone ever answered your question about the creation of
three new error messages that are almost identical to existing ones except for
the word "VIEW". For what it's worth, my feeling is that it might be cleaner
if you could in fact parameterize the existing messages so that the term
"TABLE" or "VIEW" can be passed in. But that can be done as a follow-up patch
if you are so inclined.
One other note: I noticed that there is a new "test" method for each query in
the JUnit test. Generally speaking that is not a requirement: you should feel
free to have multiple test scenarios/queries in the same "test" method if they
have something in common. Maybe you knew that and just decided to have separate
test methods, anyways--if that's the case, then no problem :) I just thought
I'd bring it up in case you were thinking each query/test case required its own
test method.
In any event, thank you for the contribution! Since the changes have been
committed I am unchecking the "Patch Available" flag. I am leaving the issue
open, though, since it sounds like you are still planning to work on the "WITH
DATA" option?
Thanks again!
> Create a table with a query
> ---------------------------
>
> Key: DERBY-64
> URL: https://issues.apache.org/jira/browse/DERBY-64
> Project: Derby
> Issue Type: New Feature
> Components: SQL
> Reporter: Christian d'Heureuse
> Assigned To: James F. Adams
> Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt,
> Derby64Patch4.txt
>
>
> I suggest to implement a SQL statement to create and fill a table with a
> query, without having to write the columns definition.
> e.g.:
> CREATE TABLE new_table AS SELECT ...;
> or:
> SELECT ... INTO new_table FROM ...;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
