Support calculated attributes about ash HOT 6 CLOSED

So for Alpha - sounds like we must have #2 done. What about #3, and #4?

Also for #1, that looks really cool. Wondering if there are benefits from that - or if it would just be used for very custom SQL that doesn't fit into what's possible with #2?

from ash.

There are benefits to #1 over #2, as for #1 they would be sortable/filterable. There are drawbacks though, as you could potentially make your queries slower for something you could have done more easily in code. However, #3 is designed to be an abstract representation that can be transformed into #1 or #2 on demand, so the framework can decide.

Also: I just realized that the spec for #2 should be something that takes a list of records and returns a list of values.

from ash.

As for which are necessary: I want to add a very limited form of 3/4, even if it’s not fleshed out to be useful, to make sure that the rest of the pipeline is ready for it. So we’d really want all of them before alpha, but for 3/4 it would only be the guts.

from ash.

This has been broken out into aggregates and calculations, and aggregates have been completed (roughly)

from ash.

The initial functional portion of calculations has been completed.

from ash.

This is all now supported.

from ash.