I need my page to know whether X number of records in a certain status exist across a several different (generally related and/or child) objects. For instance, a user should not be able to click the submit button on an application (i.e., it should be disabled) unless there are zero related records in the wrong status, at least one related record in the right status, and at least two of the right kind of contacts. Standard rollup summary fields aren’t really a sustainable solution, and in some cases I won’t be able to use them anyway since the relationships aren’t always master/detail.
Seems like I can create a model for each criteria and use “has data rows” to control the rendering of the button. Would it be helpful to use aggregate models in this kind of situation? Is this a use case for the “rollup” grouping method (and how would that work)? Would doing so potentially reduce the number of separate queries/models the page would execute? The latter is my most significant concern, I suppose, since more queries means slower response time, and there could be a dozen or so. I’m just trying to find the most sustainable and efficient approach.
This is a really interesting problem. But I think Skuid handles it really well.
I can think of two ways to do this. The first would be aggregate models as you describe. On each of the objects you are studying, count the rows where the particular status condition is true. I don’t think you need to add any groupings here - since essentially you are looking for a single Yes / No result. If there are rows you have “yes” If there are no rows you have “no”. Since you have different objects, you really can’t aggregate them together.
The other way would be to create basic models with the same conditions described above. But have the model limit set to 1 record. If the status value is found at all - you’ll get the Yes result. If no records are found - you’ll get no.
Performance is going to be your question here. I’m really not sure which type will be faster (though I suspect the second model will be because it is not doing any aggregation) I don’t think there is a means of getting around these preliminary queries.
