Barry, thanks again for reporting this.  I was able to reproduce and see the behavior you’re seeing.  I’ll update this thread when I figure out what is going on.

Barry,

This is a known issue with “Field from another Model” IN Conditions. We are working to resolve it, but for the time being there is a workaround:

 - Switch the Condition on your Grandchild Model to be:
      - Field: TestTransactionChild__r.TestTransactionParent__c
        - Operator: =
     -Value > Content: Field from another Model
      - Value > Source Model: TestTransParent
     - Value > Source Field: Id

Zach

Thanks Zach & Ben. I’ve tested and confirmed the workaround resolves the issue. Question - In our actual page, we have several different paths of grandchildren and related records (e.g. Notes related to TestTransChildren & TestTransGrandchildren). Is the workaround only required on grandchildren and below (e.g. great grandchildren) or could you provide a little more background on the issue so I know where to adjust the conditional logic in the models? Thanks again!

The issue is that “Field from another Model” IN Conditions do not reevaluate themselves when you do an updateData() call, even if you have included the Source Model(s) in the updateData() call. So essentially you’re stuck with whatever values were determined when the page was first loaded. 

The basic workaround is to avoid using “Field from another Model” IN Conditions wherever you will be trying to add / remove records from the Source Model within the same page. Field from another Model Conditions work great as long as the Source Model (e.g. TransactionChild) retains the same set of records, the trouble arises when you are adding / removing records to the Source Model and trying to reevaluate Dependent Models via an updateData query (e.g. TransactionGrandchild).

Perfect, makes sense. Thanks for the extra info Zach!

Hey guys -

This appears to be resolved at least as of 5.21.5.  Can you confirm?  Is it safe to use “Field in another model” in conditions?  Assuming yes, recommendations on which is a “better” approach (e.g. performance, etc.) of the below:

1) Subquery with “Field in another model” IN condition
2) “Field in another model” EQ condition using relationship chain (e.g. TestTransactionChild__r.TestTransactionParent__c)

Thanks!

Hi Barry,

I wouldn’t use the “Field from another Model” conditions this way until you’re on a 6.x version of Skuid.  However, once on version 6, both of these ways should work equally well.  The only difference I can think of would be in the performance of the SOQL queries that result from these conditions.

Personally, I would use method 2 whenever I could because that way the database would be handling the merge instead of having Skuid create a list of ids and sending it into the query.  Also, there could be a case where a LIMIT on your child model would cause not all of the rows to make it in.  Then when it was merged into the condition on the grandchild model, you wouldn’t have a complete query.

Hi Ben - 

Thanks for the reply and information, all makes sense.  Sounds like sticking with #2 is the best approach now and even once 6.x arrives.  Good to know that as of 6.x, option #1 will work when needed.

Thanks again!