db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5357) SQLJ.INSTALL_JAR shouldn't use identifier as file name
Date Fri, 02 Mar 2012 21:15:58 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221268#comment-13221268

Mike Matrigali commented on DERBY-5357:

I think we should consider upgrade problems, even if the previous usage was unlikely.  I suggest
that any new naming/finding
scheme be limited to hard upgraded databases, otherwise a user going back to a previous version
may "lose" their jars.

It would be cleaner if somehow a version could be associated with the naming, but I think
you still need to maintain the old naming search for old versions.  And unless you do some
sort of renaming for all existing dbs on hard upgrade, you probably
need to run both naming schemes in hard upgraded dbs.

Could somehow the new naming map a new jar to a different "old naming" file?  This could lead
to removing the wrong jar.  This
is sort of the hashing problem but from new to old rather than new to new.

It seems like hashing where 2 filenames can collide to a single is a problem, as rick points
out.  You could eliminate part of the backward compatibility problems by making new databases
use a naming scheme that could never collide with with old databases.
Maybe a new directory (jar2 ?) for new jars in new databases, or maybe there is somethink
that could not have been a valid
SQL identifier and thus could not have been an old filename (would adding a number at the
beginning of the filename work?)  

Is basing the new name on the old name a good idea still, maybe
there should just be a mapping in a catalog to a guaranteed new name, like a uuid or a sequence

> SQLJ.INSTALL_JAR shouldn't use identifier as file name
> ------------------------------------------------------
>                 Key: DERBY-5357
>                 URL: https://issues.apache.org/jira/browse/DERBY-5357
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Dag H. Wanvik
>              Labels: derby_triage10_9
>         Attachments: derby-5357.diff, derby-5357.stat
> When installing a jar file with the SQLJ.INSTALL_JAR procedure, it will copy the jar
file to a subdirectory of the database directory. The name of the stored jar file is based
on the qualified name specified by the second parameter in the procedure, and becomes something
like: <DBDIR>/jar/<SCHEMA>/<JAR_NAME>.jar.<VERSION>
> This naming scheme is problematic because the qualified name of the jar file is an SQL
identifier and may contain any characters, also characters with special meaning to the underlying
file system.
> One example is this call:
> ij> call sqlj.install_jar('/path/to/toursdb.jar', 'APP."../../../x/jar"', 0);
> 0 rows inserted/updated/deleted
> On Unix-like systems, this will install the jar in a subdirectory of the database directory's
parent directory, which is clearly unfortunate as the database directory should be self-contained
(an assumption used when taking backup of a database using operating system commands, or when
moving the database to another location).
> There's probably also a possibility that INSTALL_JAR fails if the identifier contains
a character that's not allowed in file names on the platform.
> It would be better if the jars were stored in a file whose name is independent of the
identifier used, so that any valid SQL identifier could be used to name a jar file in the
database without causing problems.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message