fixtures

[rotten]

It is sometimes useful to maintain a table of reference data (which is not modified by the application) in the database. Usually we want to manage the contents of that table in source control. Django calls these "fixtures".

A workflow would be to first run the migrations to update the table structure, and then load the fixture data.

If we are using sqitch for the migrations, what do you recommend for managing the fixtures? In the past I've written an entire fixture management system for one of my employers, but I'm trying to avoid an internal, proprietary approach. It would be awesome if it worked seamlessly with sqitch or fit this ecosystem neatly.

One of the things I really like about sqitch is the verify feature. It would be super cool if the companion fixture manager had a verify feature too.

[theory]

In the past I've just used regular changes for this, but it becomes annoying for anything that's updated more than, say, annually. But I have not otherwise given much thought to building a separate thing for fixtures. Sounds like it might be useful tho.

[rotten]

"sqixtures"

[girzel]

A good use case for deploy/revert hooks! I've wanted something similar: I keep our SQL function definitions outside of migrations, because my idea is that the migrations should just be for schema definitions, but mostly because there are long periods of time where the function definitions are changing on a near-daily basis, and managing them with migrations is a headache. I reload functions.sql after deploy, as part of the same make target, but would rather have it happen in a hook. This setup kind of sucks because it complicates sqitch revert; I haven't come up with an ideal solution yet.