[
https://issues.apache.org/jira/browse/DERBY-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13228349#comment-13228349
]
Dag H. Wanvik edited comment on DERBY-5357 at 3/13/12 7:43 PM:
---------------------------------------------------------------
Thanks, Knut!
> Could this cause problems if the database crashes during upgrade (after
> removal of old jar dir and before committing the upgrade transaction)
Yes, it could. I thought of leaving the old jar dirs in place, but that may be
no desirable either. I see SQLJ.REMOVE_JAR holds off the physical removal till
transaction commit time, maybe I can do something similar during upgrade boot.
> Could this cause memory problems during upgrade if SYSFILES is huge
In theory, sure. There is precedent code using this idiom in
DataDictionaryImpl, but you're right, I could easily merge the two methods to
avoid the issue altogether.
I also found that the upgrade test code which tests the upgraded jars with
"CALL EMC.ADDCONTACT" won't run under CDC/JSR169 (nested connection requires
DriverManager), so I'll just skip that part of the test on that platform.
I'll spin a new rev.
was (Author: dagw):
Thanks, Knut!
> Could this cause problems if the database crashes during upgrade (after
> removal of old jar dir and before committing the upgrade transaction)
Yes, it could. I thought of leaving the old jar dirs in place, but that may be
no desirable either. I see SQLJ.REMOVE_JAR holds off the physical removal till
transaction commit time, maybe I can do something similar during upgrade boot.
> Could this cause memory problems during upgrade if SYSFILES is huge
In theory, sure. There is precedent code using this idiom in
DataDictionaryImpl, but you're right, I could easily merge the two methods to
avoid the issue altogether.
I also found that the upgrade test code which tests the upgraded jars with
"CALL EMC.ADDCONTACT" won't run under CDC/JSR169 (nested connection requires
DriverManager), so I'll just skipping that part of the test on that platform.
I'll spin a new rev.
> 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: 10.9.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Dag H. Wanvik
> Labels: derby_triage10_9
> Attachments: derby-5357-2.diff, derby-5357-2.stat,
> derby-5357-with-tests-2.diff, derby-5357-with-tests-2.stat,
> derby-5357-with-tests-3.diff, derby-5357-with-tests-3.stat,
> derby-5357-with-tests.diff, derby-5357-with-tests.stat, 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
