I already posted about how to DeploymentHandler, and I specifically said I would not explain why in that post. This is the why post. TL;DR Much like recipes, I find it very tiresome when a blog post spends all its time justifying its existence instead of answering the topic. Here, then, is why I would advocate for DBIx::Class::DeploymentHandler. You only make your changes once You write those changes in Perl, not in SQL Your code and database are guaranteed to agree1 You make changes in code first, and actually deploy the database when you’re happy with it Of course, you can un-deploy and re-deploy in development as much as you like until you have something you like You have complete freedom over your result classes As opposed to changing the schema and then importing it into code, where you can’t update any of the auto-generated stuff You have complete freedom over the migrations You can edit the SQL that DH creates and it won’t notice You can add extra SQL files and even Perl scripts to be run as part of the same migration Deployment is handled by the same config file that connects your schema in the first place Or not, if you want to restrict the app’s user so it doesn’t have permission to do schema changes You can trivially automate the upgrading of your schema as part of your application’s startup You have a sequential schema version system2 Note, of course, that it only actually works if you are using DBIx::Class in the first place: but this thought leads onto the observation that any ORM in any language could be coerced into outputting the YAML format that DH uses. Read more

This post is about how to use DBIx::Class::DeploymentHandler most of the time. It does not explain why you should do it this way; if you need to know that, I’m sure I will write that post at some point as well. This module turns your existing DBIx::Class data model into either deployment scripts, or migration scripts, or both1. It does this by turning the data model into an interim data structure, which is then serialised to YAML and committed to source control. Read more

TLDR: Well executed, but good thing it was free. Probably won’t play again. When I ran out of Episode 5 of The Long Dark on stream I didn’t really know what to do with myself. I’d set aside 2 hours on a Wednesday night for this and I didn’t want to go back to just getting a good night’s sleep and a screen break! So I decided to try all of the free games I’ve been getting from the Epic store; a piece of software I only have an account on because I was promised a new Unreal Tournament was in the works. Read more

TLDR: Charming, easy to play, and great for short breaks. Play again? Likely. Each week we roll a random game that the Epic game store had for free at some point, and play it for 2 hours on stream to see how it fares. This week: Guild of Dungeoneering Perhaps the key feature of this game is its charm. Everything we do is chronicled in song. Even the main menu is an ode to the dungeoneer! Read more

TLDR: Unexpectedly great. Easy to pick up but difficult to master. Play again? Absolutely. Each week we roll a random game that the Epic game store had for free at some point, and play it for 2 hours on stream to see how it fares. This week: Speed Brawl This is one of those games where you have no idea, going in, what it is going to be like. With an emblem for a logo reminiscent of the Megadrive era (which the whole industry seems to have nostaliga for) who’s to know which, if any, of the games conjured by this image it is going to be like? Read more