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!
Grandchildren not required on Query Models action - Skuid 5.8
+13
+8Barry, 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.
+13Barry,
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
+13Thanks 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!
+13The 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).
+13Hey 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!
+8Hi 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.
+13Hi 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!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.