[
https://issues.apache.org/jira/browse/DERBY-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835774#action_12835774
]
Rick Hillegas commented on DERBY-4550:
--------------------------------------
Hi Sylvain,
I see your point about how confusing it would be if qualified names behaved
differently in some contexts. I think you are right that
PREPARE alice_conn.source_stmt AS 'SELECT * FROM T1';
should mean
" in the context of the connection alice_conn, prepare the statement
'SELECT * FROM T1' "
Off the top of my head, it seems to me that there are 3 kinds of names
recognized by ij:
1) Connection names. These are used in the CONNECT, DISCONNECT, and SET
CONNECTION commands.
2) Schema object names in the DESCRIBE commands. These are already handled by
their own production, caIdentifier().
3) Connection-scoped variables. These include the names of prepared statements,
cursors, and protocols.
I think it would be less confusing to users if all connection-scoped variables
were treated as qualified identifiers.
This brings us to the topic of what a QualifiedIdentifer is. Conceptually, I
think it is just an ordered pair of names. Probably we will get into fewer
maintenance issues if we model it that way. I don't think that we should store
prepared statements, cursors, and protocols inside QualifiedIdentifiers.
Instead, I think it would be better to use QualifiedIdentifiers to find
prepared statements, cursors, and protocols using a two step process:
i) Look up the Session by the connection name stored in the QualifiedIdentifier.
ii) Then look inside the Session for the prepared statement, cursor, or
protocol using the unqualified object name in the QualifiedIdentifer.
> 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.
