The next Galileo will allow database upgrades
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!