Explicit Migrations

[AstraLuma]

Ok, so migrations exist to allow users to make breaking changes in their models--sometimes you can only evolve a model so much.

I don't like the implicit migrations so much because:

• It makes it less clear what model given code is expecting
• Makes it harder to find the code in need of updating when a migration happens
• Just generally leaves a lot more details implicit in ways that feel like they'll bite people later

Additionally, I would like to separate data access from model migration to simplify both bits of code.

[AstraLuma]

The obvious choice is to make it a method.

I'm not a fan of post-await methods, though, like (await db.get('spam')).to(MyStruct).

This is even worse if it's in a mutate loop:

for doc in db.mutate('spam'):
    doc = doc.to(MyStruct)

[AstraLuma]

Next option is an operator, and I'm thinking @ since it's pretty rarely used in this domain.

Something like await db.get('spam') @ NewStruct

The same mutate loop becomes:

for doc in db.mutate('spam'):
    doc @= MyStruct

The major downside of this is that it's much less self-documenting, and it could be confusing to new comers.

[pathunstrom]

It's a weird operator overload, but frankly, @ as the marshal operator makes a lot of sense to me.

[pathunstrom]

So my thoughts on Migrations:

I am comfortable with migrations implicit at call time, specifically because migrations should be an ordered collection of (Vx, Vy, migration_function) structs. The hard part is "what version is in the DB" so you know where to start in the migration tree. In general, if we're doing key document, the big strength is the ability to have heterogeneous data. As long as we strictly version bits, it should be fine?

[AstraLuma]

oh yeah, the name passed to @Registry.document is what's stored in the database to identify the model.

That sounds a lot like "You're over thinking it, Jamie. The current solution is Fine, Actually."