[
https://issues.apache.org/jira/browse/DERBY-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835842#action_12835842
]
Sylvain Leroux commented on DERBY-4550:
---------------------------------------
Thanks for your comments Rick,
My first idea was to model qualifiedIdentifiers as a "pair of string". But, at
some point, I was wondering if there could be some obscure corner case where
the same session name will resolve to a different session object. That's why I
chose to model qualified identifiers as {Session,String}.
But, since there's no variable in ij, dynamic scoping shouldn't be an issue. I
will rework that way.
----
Concerning the second kind of names recognized by ij you identified:
> 2) Schema object names in the DESCRIBE commands.
> These are already handled by their own production, caIdentifier().
Even if it could be useful to examine the tables in a different connection, I
already set aside the DESCRIBE command, since offering such a possibility will
lead to difficult situations:
CONNECT '....' AS C;
DESCRIBE C.T;
Would the above statement describe the "table T of the default schema of the
connection C" - or "table T of the schema C of the current connection". For
compatibility the latter would have my preference. But it's a little bit
confusing anyway - especially if you bring it closer to a statement allowing
qualified identifier like that:
CONNECT '....' AS C;
DESCRIBE C.T; -- Here, C is a schema
PREPARE C.ST AS .... -- Here, C is a session
> 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.
