Uses for historic

[jshaffstall]

With the hello-world version of historic done, I've started thinking about whether the event source model is really suitable for the project I'd been intending to use it on. I wanted to check my thinking here.

The event source model seem to be suited mostly for:

1. Situations where you have objects that change over time

2. Situations where you need an audit trail

3. Situations where you need to rebuild the state at a certain point in time

A home bookkeeping app might benefit from an audit trail, especially if multiple family members could enter transactions, but the objects (e.g. transactions) are basically constant (save for minor edits for accuracy).

If I consider my object to be an account, with the transactions contained in the account object, then the account changes over time. But the number of transactions can grow without limit in an account, which seems like a bad idea.

Rebuilding the state at a point in time seemed like a good fit, but I realized that the date of the event isn't what I want to use for that. I'd be rebuilding the state based on transaction dates, which will likely be different from event dates, and might very well be out of order from event dates.

Am I missing something that would make the event source model a better fit than I'm thinking?

[meatballs]

For the example you describe, I'd have an account class where its instances can change over time and a transaction class whose instances are only ever created and never changed. On a transaction, I'd have an account attribute with the uuid of the account in question.

I'd then create a projection to manage a table with columns 'account' and 'transactions' - the transactions column being a simple object that holds a list of transaction uuids. That's then the table I'd use for queries.

[meatballs]

In other words, I wouldn't have a transactions attribute on the account. Instead, I'd handle that kind of 'back reference' with a projection. (That's actually a pattern I've adopted on the apps where I'm using historic - never use back-reference attributes as they involve unhelpful change events and, sometimes, revolting recursion problems. Instead, make us of projections).

[meatballs]

pseudo code for how the projection's play method might look (assuming the target table is called 'tx_by_account'):

def play(event): 
    if event["object_type"] != "Transaction":
        return
    account = event["state"]["account"]
    row = app_tables.tx_by_account.get(account=account) or app_tables.tx_by_account.add_row(account=account, transactions=[])
    row["transactions"].append(event["object_id"])

[jshaffstall]

If I were to want to generate a report for account X as of a certain date, I wouldn't be able to use event dates, it'd be transaction dates, since someone can go back and enter an older transaction they missed.

In practice that would mean I'd have to go through all transactions to rebuild to a certain point in time, which seems to not be the way event sourcing is supposed to work.

Is there a way to manage that without going through all transactions?

[meatballs]

Historic isn't an event sourcing system per se. It's based on some ideas from event sourcing, but also from CQRS.

In this case, design the table you'd like to query and then write a projection to maintain it. If a transaction has a date as an attribute, you can use that in the projection.

[jshaffstall]

Okay, I think I'm starting to see how to work with it. I'll put some more time into a prototype to see how it plays out.