Computed Column Values

[cameronmcefee]

After watching the videos, I understand that I can create computed columns like this:

public extension MyTable.TableColumns {
  var someComputedValue: some QueryExpression<Bool> {
    true
  }
}

I can then query by these values, which is helpful. However I assumed these would then be reflected in the actual data I get back, but that doesn't seem to be the case.

I suspect that I could create a @Selection struct that has a MyTable and also the computed value as properties, but that means I have to do a special query for that each time.

Is there a way to get these values into the data itself?

Here's an example that illustrates why this could be handy:

Say you've got a recipe table and a steps table, and each step has an offset from the recipes scheduled due time. To calculate how long the recipe will take, you could fetch all the steps that match the recipe id and then get the highest offset value of the steps to determine how long it takes to cook the recipe.

I could do this in Swift, but that requires me having a function that requires an input recipe and array of steps, which technically might not be associated. It'd be nice if it was just always part of the fetched data.

Can I do this somehow?

[stephencelis]

@cameronmcefee SQLite calls these "generated columns," and StructuredQueries has support documented here: https://swiftpackageindex.com/pointfreeco/swift-structured-queries/~/documentation/structuredqueriescore/definingyourschema#Generated-columns

Note that generated columns are limited to static information available to the table they're defined on and cannot refer to dynamic information (like the current date) or data from other tables. In these cases you do want to define a dynamic helper as you show above, and select this data directly from the query builder.

[cameronmcefee]

Ah, ok, I appreciate the clarification.

Some databases, including SQLite, support generated columns, which are columns whose values are computed from other columns in the same row.

I think that last part about the same row is the clarifying detail for me. I assumed these could do something across tables, but it sounds like that's just not feasible.