Proposal: Auto-Entity Action Batches

[jrista]

The nature of NgRx Auto-Entity is such that individual entities are loaded, saved, deleted discretely. There is some basic batch capability via the *Many actions, however those are still for a single kind of entity. Handling batches of actions across many entities and entity types is not currently possible.

There are use cases where many entities of different types may need to be created/updated/replaced and/or deleted, and the success and failure of all such actions as a group must then later be handled. Some kind of cross-entity, cross-entity-type batching functionality to track the correlation ids of each initiating action, then track when a success or failure for each of those initiations occurs, then finally dispatch an action when all initiation/result actions for all participants of the batch has occurred, would be extremely useful in coordinating larger and more complex multi-entity workflows.

Initial Proposal (rough idea):

1. Create the concept of a coordinated batch process in Auto-Entity, tracked in state
2. Add a new set of batched actions that can reference a batch, and internally result in the existing non-batched actions being created and dispatched as necessary
3. Batch associated with batched actions being dispatched will track the correlation ids of each standard Auto-Entity action in the associated piece of state
4. A new set of effects will observe all Auto-Entity actions, and track success or failure for each correlation Id that is a participant of the batch
5. Upon success or failure being tracked for all participants, a batch completion event would be dispatched with the results of every participant

[jrista]

This enhancement could in fact be created as an additional library that could optionally be installed along-side Auto-Entity itself. This would modularize the feature, keep it from introducing bloat into NgRx Auto-Entity core, and allow developers to choose to use it if and when necessary.

[schuchard]

This sounds interesting. Does tracked in state mean that it will store the success/failure/etc in the store and thus need to be cleaned up?

[jrista]

@schuchard Sorry, never saw your response. Tracked in state would be by some kind of transaction or batch id. I am not sure exactly when that state might be able to be cleaned up...it might need some kind of lazy handler to clean things up late, so that the state doesn't get nuked before the application has a chance to fully utilize it. But, as long as there is a unique transaction/batch id for each batch, it would eliminate the risk that multiple (even concurrent) transactions interfere with each other.