persistent expectations

[matt-beanland]

Improve the path resource so we have persistent expectations - we want to expect that a path is installed, which requires a port allocation and pairs to be cross connected from the customerSite locationId to the port on a card on a shelf at the exchange.

We may want to use placeRef to relate access places, for instance a locationId with a serving area and serving area with an exchange.

[matt-beanland]

We can take two approaches to expectations - if we twin another instance then it will need to be able to persist functions which may mean that some attributes (such as state) need to be union types. A custom outstanding function can populate expected from an instance which contains both expected and actual. We could also extend the ash_outstanding dsl.

[matt-beanland]

We want to add a 'getOutstanding' method? Or should outstanding just be a calculation we can run whenever we want?

[matt-beanland]

Tried adding an expected attribute to Path, which was a map, and setting some initial expectation in build action, however this produced a warning regarding Path's implementation of outstanding.

    warning: incompatible types given to Outstanding.outstanding/2:

        Outstanding.outstanding(expected, actual)

    given types:

        dynamic(%DiffoExample.Access.Path{}), dynamic()

    but expected a type that implements the Outstanding protocol.
    You either passed the wrong value or you forgot to implement the protocol.

    where "actual" (context AshOutstanding.TransformerHelper) was given the type:

        # type: dynamic()
        # from: lib/access/resources/path.ex:5
        actual

    where "expected" (context AshOutstanding.TransformerHelper) was given the type:

        # type: dynamic(%DiffoExample.Access.Path{})
        # from: lib/access/resources/path.ex:5
        expected

[matt-beanland]

It has taken a long while to get here but the best approach to persistent expectations is probably not to have them be directly persisted, rather to derive them from other persisted data. So we persist intent, and derive expectations.

On the expectation side, ash_outstanding could support resource DSL that defines an expectation at that level, by composing it from a number of definitions. The outstanding protocol would be extended to support expected?/1, expected/1, outstanding/1 and outstanding?/1. It would call outstanding/1 if expected/1 isn't nil (same as !expected?), i.e. if the target module can generate its own expectation. This would is pretty experimental, and requires a rethink of outstanding.

The nice part back up in diffo_example is that we can use ash_outstanding expected dsl to make the expectations of an extended resource smart, using anything we can do in ash expressions, calculations etc that run on our extended resource. We order our extension to run before ash_outstanding! That is very cool, but a real 'full-stack' PR, requiring diffo-ash_outstanding-outstanding to evolve. Probably best to seed this from the bottom up with a proposal on outstanding.