The next Galileo will allow database upgrades

I wrote Galileo partially as a reason to learn DBIx::Class. For those of you who may not know, Galileo is my CMS, designed to be completely installable from CPAN.

As a scientist I’m not very proficient as a database admin. Part of what I love about DBIx::Class is that I didn’t have to learn database administration or SQL, it does that for me. Perhaps I had gotten a little overconfident.

Not long ago, and despite my warnings in the documentation, I found out that at least one user was going into production with a Galileo-based site. While I could have said, “Aaaaargh don’t do that!”, instead I was excited and a bit nervous. I told that user that I felt like I had guest coming over and I hadn’t vacuumed in a while. There were some breaking changes to the schema in the pipeline, but I didn’t want to break the user’s site. Suddenly I had more learning to do.

Not long after, I found out that some of my column types were specific to SQLite and didn’t work on MySQL. Suddenly a schema change was not just planned but necessary.

Not knowing much SQL and certainly not knowing how to do in-place schema upgrades, I turned again to the DBIC community, and they did not disappoint. I found DBIx::Class::DeploymentHandler (known as DBICDH) which fits the bill nicely.

Using this tool I can now announce that future versions of Galileo will be able to do in-place schema upgrades as easily as it already did deployments! It will also detect the old unversioned schema and properly upgrade it too!

That said I do have a few comments. First, installing Galileo on a fresh Perl installation now installs at least 3 different object frameworks. I don’t have a small dependency radius as an explicit goal for Galileo, but it still makes me a little cringy. A p5mop cannot come soon enough! Would it be possible for DBICDH to use Moo? DBIx::Class seems to be able to make do with it.

Second, the documentation for DBIx::Class::DeploymentHandler leaves much to be desired (and gleaned from source code). Almost 2 years after Yanick wrote that DBICDH is “a wee bit terse in term of documentation”, I still found myself using his blog post as a major source of information about the module. Some more doc would be really useful. In particular, it seems to be geared towards people using DBICDH for in-house projects and not for generalized database-agnostic ones.

Third, on occasion, while DBICDH does it thing, I get what looks like Devel::Peek dumps,

SV = IV(0xb52f064) at 0xb52f068
  REFCNT = 1
  FLAGS = (ROK,READONLY)
  RV = 0xb532738
    SV = PVHV(0xb534338) at 0xb532738
      REFCNT = 1
      FLAGS = (OBJECT,SHAREKEYS)
      STASH = 0xaad7680 "DBI::db"
      ARRAY = 0x0
      KEYS = 0
      FILL = 0
      MAX = 7
      RITER = -1
      EITER = 0x0

Am I doing something wrong? Should this be happening? The results seem to work, but it looks unprofessional.

Still all-in-all, this is an amazingly powerful tool, and a great feature to be able to present to my users, namely more peace-of-mind about using my CMS!

P.S. Galileo’s development is on my GitHub. The work on versioning the database schema has been on the versioned branch, thought that may soon move to master.

1 Comment

Leave a comment

About Joel Berger

user-pic As I delve into the deeper Perl magic I like to share what I can.