db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4550) Using ij to copy data from one DB to an other
Date Fri, 19 Feb 2010 15:24:27 GMT

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


Mime
View raw message