[ 
https://issues.apache.org/jira/browse/TRAFODION-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269877#comment-15269877
 ] 

Hans Zeller commented on TRAFODION-1964:
----------------------------------------

What I can do is replace the "." (or empty string) in the external library path 
with $MY_SQROOT/udr/lib/DB__ROOT and load any libraries with relative names 
from there. All the remaining code, DDL and DML accepts relative names.

Note that this introduces an incompatibility for use cases with relative names, 
but with the current code, relative names would not work well, since the 
current work directory of the UDR server is not clearly specified. For TMUDFs 
it's nearly impossible, since two different work directories could be involved.

If you run into this incompatibility, relocate your library files from where 
they are right now (likely in $MY_SQROOT/sql/scripts??) to 
$MY_SQROOT/udr/lib/DB__ROOT.

> Cannot run SPJs after an trafodion upgrade 
> -------------------------------------------
>
>                 Key: TRAFODION-1964
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-1964
>             Project: Apache Trafodion
>          Issue Type: Bug
>            Reporter: Venkat Muthuswamy
>            Assignee: Hans Zeller
>
> The system and user SPJ jar files are now stored under 
> $MY_SQROOT/udr/lib/<user>.
> The CREATE LIBRARY/ALTER LIBRARY commands use the fully qualified linux 
> directory paths (the environment variables are expanded). 
> For example, if current trafodion build is installed under 
> /home/trafodion/build1, the files are stored under 
> /home/trafodion/build1/udr/lib/user1
> When the user upgrades and installs a new build, let's say trafodion is 
> installed under /home/trafodion/build2. 
> If the user removes this old trafodion installation, the libraries and SPJs 
> defined using build1 no longer work, because the UDR tries to load the jar 
> file from /home/trafodion/build1/udr/lib/user1 folder because that's what is 
> stored in the metadata.
> Even if the folder exists, any system created library would be pointing to an 
> older version of the jar file even though the new install might include fixes 
> to the system library jar.
> 1. Can the CREATE and ALTER LIBRARY commands use relative paths to  something 
> like $MY_UDR_ROOT  and not required the fully qualified paths?
> 2. Can the UDR runtime be modified to look at the relative paths $MY_UDR_ROOT.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to