Hitachi Vantara Pentaho Community Forums
Results 1 to 7 of 7

Thread: Table Output types

  1. #1

    Default Table Output types

    When I look at SQL for Table Output I see a lot of DROP and ADD columns. A lot of my columns are varieties of numerics like NUMERIC(20,5) which is more accurate in calculations than floating types. but I see that the SQL looks like it is going to try to redefine all of these as DOUBLE PRECISION. Is this what it is trying to do? Can I just edit this SQL and set them back to type NUMERIC or is there somewhere else I can edit these? Or is there some reason for the conversion to floats.

    Gerry

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

    Default

    If the types are very off let us know... for the rest, the create sql buttons are only meant for quick and dirty demonstrations I belief. Not to "design" your database with. And yes you can change the SQL the create sql generates.

    Do note however that the generate SQL uses the same methods as the real step, so if the results between actual and expected DDL differ widely you may be having a problem.

    Regards,
    Sven

  3. #3

    Default

    When I bring up the Select Values step the fields have attributes for Length and Precision. Right now they are all set to -1.

    Q: What does the -1 mean in terms of how the fields are treated?

    Q: As the fields move from step to step is the information about the data type for each field also being passed along and is this used at all in the Table Output step?

    C: I think Kettle should provide a data type mapping matrix that would allow the user to map an input field type to an output field type with some appropriate guessed values as defaults. For example:

    Code:
    Table Input:                                                                   Table Output:
    DBVENDOR  DBVERS    DATATYPE                      DBVENDOR  DBVERS      DATATYPE
    Postgresql     8.2.4            numeric(20,5)                  Postgresql     8.2.4              numeric(20,5)
    Postgresql     8.2.4            numeric(20,5)                  MySQL           5.1                 decimal(20,5)
    Gerry
    Last edited by greno; 10-09-2007 at 01:42 PM.

  4. #4
    Join Date
    Nov 1999
    Posts
    9,729

    Default

    That particular bug was fixed in 3.0.0-RC2. I know you are reluctant to provide details, but based on the info in the other threads I bet that's what you're using.

  5. #5

    Default

    I bet that's what you're using
    Well, uh, hmm, maybe...


  6. #6
    Join Date
    Nov 1999
    Posts
    9,729

    Default

    FYI: the precision of an Integer was set fixed to 0 in 2.5.x and in 3.0 it was given back as -1.
    -1 is our unknown flag in many of the database drivers. As such, it reverted to Double/Numeric/Float/etc depending on the database type.

  7. #7

    Default

    FYI: the precision of an Integer was set fixed to 0 in 2.5.x and in 3.0 it was given back as -1.
    -1 is our unknown flag in many of the database drivers. As such, it reverted to Double/Numeric/Float/etc depending on the database type.
    Yes, I understand that sometimes guesses have to be made. But there also needs to be a way for the user to map explicitly the fields to the data type if they so desire for the particular databases they are using.

    Gerry

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.