Grandchildren not required on Query Models action - Skuid 5.8

  • 1
  • Problem
  • Updated 4 years ago
  • Acknowledged
  • (Edited)
I have a page with 3 models (parent->child->grandchild) and a custom button that executes actions - Save Models & Query Models. After completing the actions, the grandchildren model was not updated, however all the data was successfully saved to the database. If the stock "save" button is invoked instead, all models have the correct data but I believe this is because the models are not fully requeried (only changes) during a stock "save."

I have granted login access. The test page is called SampleChildRecordsNotRetrievedAfterQueryModelRepro.

Steps to reproduce:
1) View page using test record of "TTP-0003"
2) Check the following and note the value
skuid.model.getModel('TestTransGrandchildren').data.length
3) Click the green plus icon
4) Expand the table drawer for the new row
5) Input a value for first name & last name
6) Click the green plus icon for grandchild table
7) Input a value for Information
8) Check the following and note the value - It contains 1 additional record as expected
skuid.model.getModel('TestTransGrandchildren').data.length
9) Click "Save Manual"
10) Check the following and note the value - It contains 1 less row than expected
skuid.model.getModel('TestTransGrandchildren').data.length

Actual Result:
The newly added child item does not contain visible grandchildren records in the table

Expected Result:
The newly added child should contain visible grandchildren

If you refresh the page and follow the exact same steps as above but click the "Save" button in step #9 instead of "Save Manual" the expected behavior is encountered.

Thank you!
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb

Posted 4 years ago

  • 1
Photo of Ben Hubbard

Ben Hubbard, Employee

  • 12,490 Points 10k badge 2x thumb
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.
Photo of Zach McElrath

Zach McElrath, Employee

  • 49,056 Points 20k badge 2x thumb
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
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb
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!
Photo of Zach McElrath

Zach McElrath, Employee

  • 49,056 Points 20k badge 2x thumb
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).
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb
Perfect, makes sense. Thanks for the extra info Zach!
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb
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!
Photo of Ben Hubbard

Ben Hubbard, Employee

  • 12,490 Points 10k badge 2x thumb
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.
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb
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!