db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: SQL Authorization for dblook: Progress Update
Date Sun, 31 May 2009 01:08:17 GMT
Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:

> Presumably the output will be an ij script, so the ij CONNECT command
> would be used?
>
> As far as password for user is needed, we need to think carefully
> about how to solve this issue. A approach would be to leave
> passwords open in the script to be supplied (edited in) by the data
> base owner as the script is run, or provide the dblook tool with an
> interface to fetch passwords for a given user.

If dblook starts outputting ij CONNECT commands, we introduce an
incompatibility, as the current output can be used unmodified to copy
the schema over to a new database with a different name, like this:

java org.apache.derby.tools.dblook -d jdbc:derby:db | java -Dij.database="jdbc:derby:copy;create=true"
org.apache.derby.tools.ij

This would stop working if "CONNECT 'jdbc:derby:db';" had been added to
the output.

I agree that we should not add the passwords to the output. To keep it
simple in the first iteration, we could perhaps just print a comment
stating that the statements below need to be executed as user X in order
to get the exact same dependencies as in the original database. That's
consistent with what dblook currently does for the initial connection,
it prints the URL in a header comment instead of printing a CONNECT
statement.

If we later find an elegant solution to this problem, it should be
fairly easy to replace the comment with whatever we come up with. But I
don't think the lack of an elegant solution at this point is a
showstopper, as printing the DDL in sorted order would be a great
improvement by itself.

-- 
Knut Anders

Mime
View raw message