Hitachi Vantara Pentaho Community Forums
Results 1 to 10 of 10

Thread: Bug or Feature? with shared objects file

  1. #1

    Default Bug or Feature? with shared objects file

    Hi folks,

    I have an "issue" with using a shared object file. I don't know if this is a bug or some kind of feature I don't understand, so I post it here and am willing to open a bug report if it is a bug.

    My problem is Spoons seems to copy shared connections into a transformation upon closing.
    Try the following (using no repository):
    1. Open Spoon
    2. Create a new Transformation and save it.
    3. Set the Shared Object File property to:
    ${Internal.Transformation.Filename.Directory}/shared.xml
    4. Create a DB connection and share it.
    5. Close the Transformation
    6. Reopen the Transformation
    7. Now you can see a not shared DB Connection (you can verify this by looking into the ktr file, there is a DB Connection defined)
    8. Delete this Connection and open the Transformation Settings dialogue and voila the shared connection is back again.

    Is this intended? (Kettle version is 3.0.1 on a Linux machine)

    Greets,
    Christian

  2. #2
    Join Date
    May 2006
    Posts
    4,882

    Default

    Try not using ${Internal.Transformation.Filename.Directory} in the shared objects filename.

    Regards,
    Sven

  3. #3

    Default

    First: Thanks for the swift answer. The support in this forum is amazing.

    Now to your suggestion:
    Without the relative directory variable it works as it should.

    Hmm, so I cannot use variables in the location of the shared objects file?

    Any alternatives to define relative paths? I need this because I have lots of transformations on the same connection and need to have the whole project in a CVS repository.
    Can I somehow set ${KETTLE_SHARED_OBJECTS} to a relative path (relative to the current transformation directory) ?

    greets,
    Christian

  4. #4
    Join Date
    May 2006
    Posts
    4,882

    Default

    I don't think you can use the Internal variables in a reliable way for the shared objects name at design time (it would work at runtime).

    Can you try defining a variable in kettle.properties pointing to your shared connection file and use that... and then report back whether the problem still occurs or not.

    Regards,
    Sven

  5. #5

    Default

    I just quickly looked into the source.

    The problem seems to be, that in the process of loading XML to TransMeta the Internal.Transformation. .. variables are set at the very end and the shared objects are read at the beginning, meaning that the variable subsitution fails.
    If I reopen the Settings dialogue the shared objects are read again and the variable subsitution works. Seems like an easy two line fix moving the setting of the internal variables to the beginning of loadXML and setting the fileName property before the xml loading?


    greets,
    Christian
    PS: The variable subsitution from kettle.properties works.
    Last edited by ChBeutenmueller; 01-02-2008 at 08:00 AM.

  6. #6
    Join Date
    May 2006
    Posts
    4,882

    Default

    The problem is that the Internal depends on the runtime... if you open several transformations in spoon in different locations variable management would be a mess (at designtime), so that's why it's currently not completely reliable to use Internal variables in the shared object name

    Regards,
    Sven

  7. #7

    Default

    I see, so what can I do?

    For me (as a non-repository user) it seems that my little quick fix (just moving the setting of the filename and the initializing of the internal variables a bit in TransMeta.loadXML) greatly improves the situation.
    Attached Files Attached Files

  8. #8
    Join Date
    May 2006
    Posts
    4,882

    Default

    I'll see... it will remain a hack... try with your patch to switch between transformations e.g. in spoon.

    Regards,
    Sven

  9. #9

    Default

    Oops, there was a little issue with that patch.
    I think I got it, though twice setting the filename property isn't nice either .. makes it look more ugly though.
    Attached Files Attached Files

  10. #10

    Default Problem with shared object connections continued

    Hey Sven,

    You've written earlier that the issues with the shared objects should not affect the runtime. I got a bunch of the aforementioned Transformations with relative paths to their shared.xml called from a Job. If I start it with Kitchen it seems to work.

    But the only reason why it seems to work is that the shared connections are saved also inside the Transformations (The code to save TransMeta to XML doesn't check if it is shared).

    If I manually delete these <connection>..</connection> elements in the Transformation xml file it doesn't work anymore.
    Another test is changing some parameters in the shared file and you'll see that they are ignored at runtime.

    Seems to me like Internal.Transformation.Filename... variables don't work at all for the shared object path inside a Transfomation.

    Greets,
    Christian

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.