Hitachi Vantara Pentaho Community Forums
Results 1 to 7 of 7

Thread: Filter Rows not working

  1. #1

    Default Filter Rows not working

    Hi all

    I dont know why but when I am using the filter rows step in my transformation the flow of the transformation goes through all the possible branches...... it seems that not only is not filtering correctly, it is distruting the flow of the data through all possible ways.
    Comprobar_Num_Pedidos.ktr

    I think the origin of the problem is that the field to filter by it is obtained in a "Table Input" step and the data type is not well defined. I have tried to solve this using a "Select Field" step to define the data type... but no matter what I use (Binary, String, Integer, Boolean).... I am not able to get the filter row to work.

    Am I doing anything wrong? here I pass you my transformation.,

    Thanks a lot!

  2. #2
    Join Date
    Nov 2013
    Posts
    382

    Default

    You have a misunderstanding about pipe processing on PDI.

    All steps start at once. As soon as they receive rows, every step deals with them and write to the next step on the pipe.

    But ... INPUT steps don't wait for any input from the pipe, they generate their own data. Step "Ver si hay 20 pedidos" starts as soon as the transaction initiates, not waiting for anything on the pipe.

    Net effect: the row (just one) from "Ver si hay pedidos retrasados" reaches the Filter row and goes either to "Add constants 1" or "Ver si hay 20 pedidos" depending on the value. But the "Ver si hay 20 pedidos" step already got his own data and this row is far away on the pipe already.
    Last edited by DepButi; 01-11-2018 at 12:23 PM. Reason: typos

  3. #3
    Join Date
    Jun 2012
    Posts
    5,534

    Default

    Of course, the Filter-Rows step is working as designed.

    A well suited test would look like this:


    Name:  230738.png
Views: 765
Size:  10.3 KB


    Don't add 17 steps to a transformation before you have a firm grasp of the concepts involved.
    So long, and thanks for all the fish.

  4. #4

    Default

    Ahhhh!!.. got it thanks so much for this clarification!! DepButi. I think the best I can do is spliting these transformations in two and launch them in the same job communicating them by the use of Variables.
    Gonna try it that way!, thanks a lot once more for this!

  5. #5
    Join Date
    Nov 2013
    Posts
    382

    Default

    Easier: check "execute for each row" on "Ver si hay pedidos retrasados" and you are done.

  6. #6
    Join Date
    Apr 2008
    Posts
    4,690

    Default

    Quote Originally Posted by DepButi View Post
    Easier: check "execute for each row" on "Ver si hay pedidos retrasados" and you are done.
    Doing that might kill performance.
    You might end up with a single update statement that should be run once being run hundreds of times...

    Sometimes, a Job is the right answer. Sometimes not.

  7. #7
    Join Date
    Nov 2013
    Posts
    382

    Default

    The first Table input produces only ONE row, so the second table input will execute maximum once.

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.