[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ https://issues.apache.org/jira/browse/DERBY-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4550: -- Fix Version/s: 10.6.1.0 > 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 > Fix For: 10.6.1.0 > > 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, DERBY-4550_6.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.
[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ 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_6.patch Sorry about that, Rick... Here is a 6th version of the patch. This time I double-checked - everything should be all right. M java/tools/org/apache/derby/impl/tools/ij/ConnectionEnv.java M java/tools/org/apache/derby/impl/tools/ij/ij.jj A java/tools/org/apache/derby/impl/tools/ij/QualifiedIdentifier.java M java/testing/org/apache/derbyTesting/functionTests/tests/tools/ij7.sql M java/testing/org/apache/derbyTesting/functionTests/master/ij2.out M java/testing/org/apache/derbyTesting/functionTests/master/implicitConversions.out M java/testing/org/apache/derbyTesting/functionTests/master/nonreserved.out M java/testing/org/apache/derbyTesting/functionTests/master/ij7.out M java/testing/org/apache/derbyTesting/functionTests/master/cursorerrors.out M java/testing/org/apache/derbyTesting/functionTests/master/holdCursorIJ.out > 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, DERBY-4550_6.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.
[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ 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.
[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ 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_4.patch Forgot to add QualifiedIdentifier.java in the patch. > 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 > > > 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.
[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ https://issues.apache.org/jira/browse/DERBY-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Leroux updated DERBY-4550: -- Attachment: (was: DERBY-4550_4.patch) > 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 > > > 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.
[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ https://issues.apache.org/jira/browse/DERBY-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Leroux updated DERBY-4550: -- Issue & fix info: [Patch Available] > 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 > > > 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.
[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ 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_4.sql DERBY-4550_4.patch Attaching a new patch for this issue. Currently, Session objects hold reference for prepared statements, cursors/cursor statements and asynchronous statements. All now accept the '@' notation to design an identifier outside of the current connection. See the attached SQL file for example. Add some tests to ij7.sql. Changed a test result in ij2.out to reflect the fact that error messages now provides the session name as well as the faulty statement: ij> Connect 'jdbc:derby:memory:dummy;create=true'; ij> EXECUTE stmt; IJ ERROR: Unable to establish prepared statement s...@connection0 Pass derbytool and ToolScript test suites. Ready for review. > 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 > > > 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.
[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ 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_3.sql DERBY-4550_3.patch Attaching the third version of this patch. The following statements now use qualifiedIdentifiers: - PREPARE - EXECUTE ... USING ... - REMOVE - GET CURSOR - NEXT/PREVIOUS/FIRST/LAST/BEFORE FIRST/AFTER LAST/RELATIVE/ABSOLUTE/GETCURRENTROWNUMBER - CLOSE I added support for qualified identifiers on cursors as well, since I think it might be useful (as part of a different JIRA issue) to extend EXECUTE in order to accept cursors in the USING clause. I add some tests at the end of ij7.sql. I wasn't able to add GETCURRENTROWNUMBER in the test suite since it writes directly on the output, and somehow, the test tool does not take that output into account. I filed a JIRA issue on this (DERBY-4553). ToolScript test suite ran without any error. > 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 > > > 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.
[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ 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_2.sql DERBY-4550_2.diff Concerning the PREPARE statement: ij> prepare fred_conn.second_select as 'select * from t1'; >From the user point of view, I think it could be frustrating to discover that >qualified names are allowed, but only if it refers to the current connection. Couldn't it be more consistent to: 1) only allow unqualified identifiers here, thus enforcing the fact that you only can create/remove an identifier in the current connection's namespace. 2) /or/ allow qualified identifiers here, allowing implicitly to create identifiers in an other connection's namespace. After a second thought, the later has my favors. Since it made possible to create/use/remove a prepared statement without requiring to explicitly switch connection: ij> CONNECT '.' AS alice_conn; ij> CONNECT '' AS fred_conn; ij> PREPARE alice_conn.source_stmt AS 'SELECT * FROM T1'; ij> EXECUTE 'INSERT INTO T2 VALUES(?)' USING alice_conn.source.stmt; ij> REMOVE alice_conn.source_stmt; With that option, the above PREPARE statement has for meaning: " in the context of the connection alice_conn, prepare the statement 'SELECT * FROM T1' " I attach both a patch and sql example to demonstrate that option. > 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 > > > 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.
[jira] Updated: (DERBY-4550) Using ij to copy data from one DB to an other
[ 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.sql DERBY-4550.diff Here is a first attempt to solve this issue. Basically, I add an optional "ON" clause to the PREPARE statement, allowing to prepare the statement on an alternate connection, instead of the current one. I don't know if this is the most elegant way of doing, but it appears to work. The file DERBY-4550.sql contains a sample script demonstrating that. As Rick Hillegas suggested it on the mailing list, I will take a look at PreparedStatement.addBatch() and Statement.executeBatch() for an alternative option. I focused mostly on prepared statements as it was my first idea. But cursors might benefit of the same improvement. > 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 > > > 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.
