AshVersioned

• code :: https://github.com/sfoxhq/ash_versioned
• issues :: https://github.com/sfoxhq/ash_versioned/issues

Resource versioning for Ash using Slowly Changing Dimension (type 2). There are multiple approaches to SCD type 2, but AshVersioned uses a version number column and a flag indicating the current version.

Compared to other approaches

Ash has three other approaches that answer the question "what did this resource look like before?" AshVersioned requires a structural commitment to the core resource definition, whereas the other options place history in separate tables.

• ash_paper_trail stores historical records into a generated Version linked resource: one history table per versioned resource with matching column definitions.

• ash_events and ash_event_log store historical records as event logs into a single history table for the entire application. This makes tracking any change across the entire database easy.

  • ash_events stores the action and its inputs, not just the resulting values, so state can be replayed and rebuilt from the event stream. This makes it closer to event sourcing than an audit trail.

  • ash_event_log is the lightest alternative: audit-only, no replay, and logged out-of-band so it doesn't sit in the write path.

AshVersioned trades the lower friction of out-of-band history for uniformity and durability.

AshVersioned uses one variation of SCD type 2. As stale rows have their update timestamps modified when they become stale, it shares many similarities with a (uni-) temporal table. AshVersioned is not designed for temporal use and cannot readily support more complex temporal types.

Installation

Add ash_versioned to your dependencies in mix.exs:

def deps do
  [
    {:ash_versioned, "~> 0.1"}
  ]
end

Documentation is found on HexDocs.

Tutorials

• Getting Started with AshVersioned

Topics

• The versioning model
• Options

Reference

• AshVersioned.Resource DSL

Semantic Versioning

AshVersioned follows Semantic Versioning 2.0.