[
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.
