db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Leroux (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
Date Wed, 24 Feb 2010 13:42:28 GMT

     [ 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 JDK4@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 P1@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.

View raw message