Evaluate Formula Fields earlier in the "Create New Row" processing steps

Currently, formulas are evaluated near the end of the “create new row” process.  The result of this is that formula field values are not available to use when setting default values, etc.

In thinking this through, from a technical perspective, as soon as the “row” object is created, the formula fields exist and therefore should have a value.  

During the “create new row” process, updateRow is called in a few different places for different reasons (e.g. setting default values).  UpdateRow processing will evaluateFormulas as well but if a formula relies on a formula, the value wouldn’t be calculated correctly.

This stems from Bill’s post at https://community.skuid.com/t/ui-field-formula-to-return-current-time.

Couple of questions:

1) Was placing the evaluateFormulaFields near the end of the createRow process intentional?
2) Does it make sense to make this call sooner in the process?



In answer to your questions:

1) Yes, placing evaluateFormulaFields near the end of the createRow process was intentional. This to allow formulas that depend on values in the same row to be able to evaluate. 

2) Based on the above response, its better to call evaluateFormulaFields at the end.



I am changing this to an idea under consideration for our devs to consider … Vote this issue up if you agree with Barry!


Hi Karen -

Thanks for the reply and info and changing this to an idea!

If my understanding of how formulas works is correct, if the formulas are moved to earlier in the process, the following would occur:

1) Formula fires that relies on field value in same row - since there is no value yet, the formula would just use null/empty behavior.  No harm done here.
2) Other field gets updated on same row - this will end up calling UpdateRow which will, in turn, call evaluateFormulas which will then result in formula field evaluating again, this time on the value from the field that was just updated.  

Changing to this approach would yield the following benefits:

1) Formula fields would always have a value
2) Formula fields could be used in establishing defaults, etc.

I’d have to spend some time really thinking this through some more and reviewing code but I don’t think this would introduce any performance impact since it’s just moving code that is already getting called to another location in the process. If there is a performance impact, I think it would be negligible and performance is the only potential downside that I could see to making this change.  If this change were made, it should be completely transparent to everything but with the benefits listed above.