As I'm working on my Veure project, I've used DBIx::Migration to handle database migrations. If you're familiar with this module, this might seem like a surprising choice since it is, well, awful. However, I know exactly what the limitations are and since I'm so familiar with it, I now have a custom Veure::DBIx::Migration. There are several things I find useful about this.

• It's not tied into a specific ORM.
• It's very simple.
• It's easy to fix and make PostgreSQL-specific hacks I need.

Actually, that's almost a lie.

If you've been using Subversion or (shudder) CVS, you only have the briefest glimmerings of what source control is about. I don't really like having to dig too deeply into tools that I use. I want them to be easy, but I dig when something's hard.

On thing which frustrated me about Subversion is that fact that, as mentioned, I don't think about some things. More than once I've quickly hacked up a change to a module, switched other modules to use that module and do a quick svn rm and svn add.

Oops. I just lost my version history. Damn it.

Not with git. It figures it out for me. My Veure project uses DBIx::Class::Schema::Loader because I don't want to think about building my schema classes. The 0.5003 version is fantastic. It does a better job of naming relationships and the DBIx::Class::Schema::Loader::DBI::Pg support is fantastic.

But what happens if you rename a table? I've done this more than once on my new project, continually working to ensure that I keep things clean and consistent. Unfortunately, that means that a renaming the foo_bar table to foo means that a different schema class is created, separate from the old one. Naturally, I don't think about this and I do a quick git rm and git add.

And git sees what I did and it realizes that the file has been renamed and I don't lose my history.

From what I read (I could be wrong), git actually uses heuristics to determine whether or not a file has been renamed, but so far it's worked flawlessly for me. I am still using Subversion at work (I've not felt comfortable checking out the git-svn work, but that's me being silly), and it's just painful. I doubt I'll ever use Subversion for a personal project again.

Update: came into work this morning and was asked to merge one branch into another. It was conflict hell and I was having trouble figuring out all of the changes. A colleague, using git-svn, merged the two branches cleanly, no problem. I think it's time for me to learn git-svn now.

There are three things that I really love about Perl:

• Moose
• Catalyst
• DBIx-Class

That's where the problem starts. It's not really a BBC problem, though. It's a problem for all "enterprise" customers.

I had written about Testing With PostgreSQL and today discovered some failing tests. It turns out this is because I had migrated a database down two levels, altered a table, and migrated it back up (I can do this because no one is relying on a production copy). Unfortunately, when I migrated it back up, the new tables didn’t have their correct triggers assigned because the _test_changed_table check was in place. As a result, my test module assumed the testing system was in place.

I've been working on a personal project lately and I decided that, amongst other things, I was going to use PostgreSQL. Some of you may recall that I had an interesting testing strategy for MySQL. The basic idea is that I don't want to teardown and rebuild the database for every test. Truncating a table is generally much faster than dropping and recreating it. However, if I leave the database up, how do I guarantee it's always in a pristine state? One way is to use transactions and always roll them back at the end of a test. That means, amongst other things, that I can't easily test "commit". You can make it work with nested transactions (if your database supports them), but "rollback" can cause issues.

There's also the problem that by breaking "commit", you're altering the behavior of your code somewhat. Plus, if you have more than one process, unless you can share the database handle, separate processes can't see what's happening in another's transaction.

My strategy is not one that everyone is comfortable with, but I prefer to track the changes to the database and simply truncate tables which have changed, possibly restoring the "static" data which some tables need to have when the app is launched. Making this work with PostgreSQL really helped me to relearn a lof things I had forgotten about this excellent database. Here's the full code, with some interesting goodies you may not have expected (plus some hacks I need to fix at some point).