Snapshot in aggregate8 example won't work for custom object in aggregate about eventsourcing

[johnbywater]

What happens if you make the Trick class a Pydantic class, inherit from BaseModel?

[johnbywater]

Hi @zhangcheng,

I had a look into this a bit more today, and adjusted the aggregate examples 7 and 8, so that there is a Trick class, which is used in both aggregate events and aggregate state, and which is reconstructed from serialised string values, representing only the name of the trick, from both recorded aggregate events and from recorded snapshots.

I did it both for the immutable aggregate class in example 7 which is coded in the functional style, and also with the mutable aggregate class in example 8 which is coded in the declarative style.

The example 7 is fairly straightforward: the aggregate events and the aggregate class are defined as Pydantic models that mention the Trick class in their annotations. So when they are constructed from dict representations the Trick objects are reconstructed by Pydantic.

The example 8 is also quite straightforward: there is a Snapshot class defined on the Dog class is a domain event, and so it is a Pydantic model, that has a DogState type that mentions the Trick class. The slightly tricky thing here was to make Pydantic also carry the extra attributes of the aggregate base class (_created_on and _modified_on but potentially other things in future, or in other people's code). I adjusted the library to support this defining snapshot classes on aggregate classes, so that when taking snapshots an application uses either a snapshot class defined on the aggregate (this is new) or otherwise the snapshot class defined on the application class (as before). Then, when the aggregate is reconstructed from a snapshot, the stored event representing the snapshot is mapped into a Dog.Snapshot object, rather than the usual Snapshot class as before, because of the stored event topic, and then the Trick objects in the state are reconstructed by Pydantic because they are mentioned on the Dog.Snapshot class. The Dog aggregate is then reconstructed in the normal way, by injecting the state of the snapshot into a new Dog instance. I tried a couple of other approaches, such as extending the Snapshot.mutate() method, but eventually ended up with the code you can see in the docs.

https://eventsourcing.readthedocs.io/en/latest/topics/examples/aggregate7.html
https://eventsourcing.readthedocs.io/en/latest/topics/examples/aggregate8.html

Definitely open to suggestions for improvements and/or alternatives. Let me know what you think?

[johnbywater]

It also works with Pydantic v2...

[zhangcheng]

Cool, will check out the details in a while.
I just saw that you updated the library a few minutes ago when I ran poetry update in my project. 😄

Updating eventsourcing (9.2.20 -> 9.2.21)

[zhangcheng]

What happens if you make the Trick class a Pydantic class, inherit from BaseModel?

Ah, nice, this works with pydantic 1.10.12.

class Trick(BaseModel):
    name: str

But if I try to upgrade to pydantic 2.2.1, I ran into the same issue as above.
It was my original intention to use with pydantic v2, but looks like now it won't be an painless upgrade. :-(

[johnbywater]

Great news that it works with v1 at least. Well done!

Maybe this page might help with the migration to v2: https://docs.pydantic.dev/latest/migration/

If you can figure this out, we can also update the docs :)

[johnbywater]

I will close this issue now, but if you want to reopen please feel free.

[johnbywater]

Cool, will check out the details in a while.

Great!

I just saw that you updated the library...

Yeah that fixed an issue raised in #261.