Data “batches” are one of the most powerful features of Rattail / Tailbone. However each “batch type” is different, and they usually require custom development. In all cases they require a Rattail-based app database, for storage.
You can think of data batches as a sort of “temporary spreadsheet” feature. When a batch is created, it is usually populated with rows, from some data source. The user(s) may then manipulate the batch data as needed, with the final goal being to “execute” the batch. What execution specifically means will depend on context, e.g. type of batch, but generally it will “commit” the “pending changes” which are represented by the batch.
Note that when a batch is executed, it becomes read-only (“frozen in time”) and at that point may be considered part of an audit trail of sorts. The utility of this may vary depending on the nature of the batch data.
Beyond that it’s difficult to describe batches very well at this level, precisely because they’re all different.
In most cases the table(s) underlying a particular batch type, have a “static”
schema and must be defined as ORM classes, e.g. within the
In some rare cases the batch data (row) table may be dynamic; however the batch header table must still be defined.
Once the batch table(s) are present, the next puzzle piece is the batch handler. Again there is generally (at least) one handler defined for each batch type.
The batch “handler” is considered part of the data layer and provides logic for populating the batch, executing it etc.