[
https://issues.apache.org/jira/browse/DERBY-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Leroux updated DERBY-4550:
----------------------------------
Attachment: DERBY-4550_5.patch
Here is the 5th version of this patch.
As I suspected first, the errors in some tests are caused by the fact that ij
now reports the connection as part as the identifier when an error in
encountered.
As you noticed here, this slightly breaks the observable behavior of ij. But I
think from an user point of view it is important to report the connection name
as well as the unqualified identifier in order to clearly distinguish a faulty
statement.
I chose to update all the related tests in order to reflect that. Here are some
examples of such changes (extract from the attached patch):
Index:
java/testing/org/apache/derbyTesting/functionTests/master/holdCursorIJ.out
[...]
-IJ ERROR: Unable to establish cursor
+IJ ERROR: Unable to establish cursor j...@connection0
Index:
java/testing/org/apache/derbyTesting/functionTests/master/implicitConversions.out
[...]
-IJ ERROR: Unable to establish prepared statement P1
+IJ ERROR: Unable to establish prepared statement p...@connection0
Now pass the following tests without any error:
java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
java org.apache.derbyTesting.functionTests.harness.RunSuite derbytools
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.lang.LangScripts
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.tools.ToolScripts
----
Concerning a possible use of qualified identifiers in the PROTOCOL statement:
I didn't notice a previous comment on this:
> 3) Connection-scoped variables. These include the names of prepared
statements, cursors, and protocols.
In fact, protocols are not connection-scoped: protocols identifiers are
currently bound the parser instance, not to a session object. It feels like
some kind of global identifier to me. Moreover, the PROTOCOL statement could be
issued before opening any connection (i.e.: before any session object was
available):
sh$ java org.apache.derby.tools.ij
ij version 10.6
ij> PROTOCOL 'jdbc:derby:memory:' AS memory;
ij> CONNECT 'a;create=true;user=fred' PROTOCOL memory;
ij> CONNECT 'b;create=true' PROTOCOL memory;
Please note I never really used that statement, so it's quite possible I missed
some important point here.
----
An other possible candidate for qualified identifiers could be the DESCRIBE
statement. But I think this is part of an other issue, since DESCRIBE requires
some special treatment (it uses its own production caIdentifier).
> Using ij to copy data from one DB to an other
> ---------------------------------------------
>
> Key: DERBY-4550
> URL: https://issues.apache.org/jira/browse/DERBY-4550
> Project: Derby
> Issue Type: Improvement
> Components: Tools
> Reporter: Sylvain Leroux
> Assignee: Sylvain Leroux
> Priority: Minor
> Attachments: DERBY-4550.diff, DERBY-4550.sql, DERBY-4550_2.diff,
> DERBY-4550_2.sql, DERBY-4550_3.patch, DERBY-4550_3.sql, DERBY-4550_4.patch,
> DERBY-4550_4.sql, DERBY-4550_5.patch
>
>
> It is possible to have open connections to several databases while running
> ij, but it is not currently possible to copy data from one DB to an other one.
> Not only such a feature would allow to copy data between Derby databases.
> But, ij being mostly DB agnostic, if will ease import/export from any JDBC
> compliant data source.
> See
> http://old.nabble.com/Using-IJ-to-copy-data-from-one-DB-to-an-other-one-td27598138.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
