Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <2124425006.389651266593067869.JavaMail.jira@brutus.apache.org>
Date: Fri, 19 Feb 2010 15:24:27 +0000 (UTC)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4550) Using ij to copy data from one DB to
 an other
In-Reply-To: <2119585497.297391266319888052.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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