A piggy bank of commands, fixes, succinct reviews, some mini articles and technical opinions from a (mostly) Perl developer.

How to use DBIx::Class::Migration

There is a tutorial (note: links are broken), but this is a cheat sheet:

Use case A: Developing - initial setup

Step 0: Set up a database instance

Use dbdeployer, it's great.

Step 1: Generate the DBIx::Class Result classes

  • dbicdump
    • dbicdump -o dump_directory=lib -o components='["InflateColumn::DateTime"]' Smurf::Foo::DB 'dbi:mysql:database=foo;host=127.0.0.1;port=8022;user=msandbox;password=msandbox'
    • ...this will create:
      • lib/Smurf/Foo/DB.pm
        • Manually add: our $VERSION = 1; to this at the end.
      • lib/Smurf/Foo/DB/Result/Table1.pm, etc.

Step 2: Generate the DBIx::Class::Migration files

  • dbic-migration prepare
    • dbic-migration -I lib prepare --schema_class Smurf::Foo::DB --target_dir=share --dsn='dbi:mysql:database=foo;...etc'
    • ...this will create:
      • share/migrations/_source/deploy/1/001-auto.yml
      • share/migrations/_source/deploy/1/001-auto-__VERSION.yml
      • share/migrations/MySQL/deploy/1/001-auto-__VERSION.sql
      • share/migrations/MySQL/deploy/1/001-auto.sql
      • share/fixtures/1/conf/all_tables.json

Notes and gotchas

  • If you see a definition for dbix_class_deploymenthandler_versions anywhere, i.e. in lib/Smurf/Foo/DB/Result/DbixClassDeploymenthandlerVersion.pm then you're gonna have a bad time. This could mean you accidentally ran dbicdump after dbic-migration prepare. It will cause migrations to fail when they try to create the dbix_class_deploymenthandler_versions table from both 001-auto-__VERSION.sql and 001-auto.sql

Use case B: Making changes to the database

Step 3: Make changes and update files

  • Do not write any SQL
  • Make changes to the DBIC classes under `lib/Smurf/Foo/DB/Result`, but DO NOT MODIFY THE FIRST PART OF THE FILE (see DBIx::Class::Schema::Loader comments in those files)
  • Bump the version in `lib/Smurf/Foo/DB.pm` (or add it - at the bottom outside the auto-generated section: `our $VERSION = 2;`
  • Run `dbic-migration prepare --schema_class Smurf::Foo::DB --target_dir=share --dsn='dbi:mysql:database=foo;...etc'` to create a new migration in the `share` directory
  • Run `dbicdump -o dump_directory=lib -o components='["InflateColumn::DateTime"]' Smurf::Foo::DB 'dbi:mysql:database=foo;...etc'` to see if it makes any updates to the first part of the DBIC classes under `lib/Smurf/Foo/DB/Result`

Use case C: Not making changes to the database

Step 4: Install and upgrade as needed

  • Run dbic-migration install --schema_class Smurf::Foo::DB --target_dir=share --dsn='dbi:mysql:database=foo;...etc'
  • Run dbic-migration upgrade ...etc

Pinto commands, working with pinto and cpm

# Check what's in Pinto CPAN mirror:

pinto list --root $PINTO_MIRROR | grep Your::Module | head -1

# ...or do the same locally (note the space after the module name)

grep 'Smurf::Foo ' ~/.perl-cpm/sources/$DARKPAN/02packages.details.txt

# Downgrade a module using cpm

cpm install --reinstall --no-prebuilt --resolver metadb --resolver 02packages,$DARKPAN_NAME $DARKPAN_FQDN_WITH_BASIC_AUTH/authors/id/U/UB/UBUNTU/Smurf-Foo-1.23.tar.gz


Windows command prompt get set environment variables

Yuck. I feel dirty writing about the Windows command line, but sometimes you just need to get a job done.

View all environment variables

reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment"

View a specific environment variable, e.g. PATH

reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v PATH

Set an env var locally (not persistent)

set FOO="foo"

Set an env var globally (persistent) - must be run as administrator

setx BAR "bar" /M

View individual local env vars

echo %FOO%

echo %BAR%