When to use stored calc over calc

I understand one of the main differences between the two is that a stored calc has a column in the table which can be sorted, filtered, etc on. I can’t seem to find good examples of when to use a calc field instead of a stored calc field.

An idea I can think of is to use a calc field for referencing FK fields. I’m not sure if the performance would be the same as just doing a fetch with nested include statements though.

1 Like

They have different use cases. Stored calc fields will be automatically invalidated when any underlying dependencies change. This can be expensive if the field is not used frequently but the underlying dependencies are constantly changing.

Since calc fields are read only and lazy evaluated (the expression will only be evaluated when the field is read), if the field is infrequently used but the dependencies are changing frequently, then labeling that field calc usually makes more sense.

I will make sure to update the documentation to clarify the different use cases.

Lets say you have a type with thousands or millions of records (pretty common). You want to add a calc field, and you’re trying to decide whether to ‘store’ it.

Generally, you should store a calc field if:

  • You are going to use it as a filter when fetching this type
  • You are going to use it to to sort records of this type
  • You will be displaying the aggregated results of this field value across all instances of this type (e.g. a distribution
  • You will show many records of this type and including this field (e.g. in a grid or list page)

Generally, you should not store a calc field if:

  • You access it for one instance of a type at a time (like on a record detail page)
  • You rarely access the value directly, you just use it to calculate something else