[Dbix-class] DBIx::Class::DeploymentHandler::Simple (working name) RFC

[fREW Schmidt]

Hello All!

So I wrote DBIx::Class::DeploymentHandler 3~ years ago to solve all
possible needs.  It works pretty well and I'm happy with the way I've
been able to extend it to meet my needs.  *But* as many of you know
(more than me for sure) DBICDH is not an easy tool to jump into.  I'd
like to solve (some) of this.

At work I will (with the current architecture) need to make a singificant
number of DBICDH subclasses, despite the fact that the only thing I'll
be doing is changing the name of the version storage table.  So with
that in mind I'll be making a new DBICDH.

So far I have a few things in mind:

 * instantiate time setting of the version storage table name
 * optionally remove the storage type directory
 * optionally remove the option for downgrading
 * optionally remove the distinction of deploying

The first I've already described.

The second makes sense in retrospect.  If you are unfamiliar with
DBICDH, the typical filename is:

 $script_dir/mysql/upgrade/1-2/001-install-users.sql

if the storage type is disabled, it becomes:

 $script_dir/upgrade/1-2/001-install-users.sql

I suspect this will be quite common, as most people seem to just
deploy to a single database type, myself included.

The third is in a similar vein.  I actually do no ever downgrade and
instead opt to just restore backups, as they will work every time
without me having to look at them.  If a user modified the first
example by disabling downgrades they would see this:

 $script_dir/mysql/upgrade/2/001-install-users.sql

So instead of `1-2` it's just `2`, as in the second migration.

The fourth is again a simplification measure.  If you use DBICDH as I
intended it, you always install version 1 and then run the migrations
in order after that.  That should mean that instead of the following
files:

 $script_dir/mysql/deploy/1/001-install-states.sql
 $script_dir/mysql/upgrade/1-2/001-install-users.sql

there would be:

 $script_dir/mysql/upgrade/0-1/001-install-states.sql
 $script_dir/mysql/upgrade/1-2/001-install-users.sql

If the user disables downgrading and deploying, the above would
become:

 $script_dir/mysql/1/001-install-states.sql
 $script_dir/mysql/2/001-install-users.sql

And finally, if the user also disabled storage type they'd have:

 $script_dir/1/001-install-states.sql
 $script_dir/2/001-install-users.sql

I also have one other idea in mind.  Currently the VersionStorage
depends on the autoincrementing `id` being in order, and it turns out
in some situations (database replication for example) that is not the
case.  With that in mind I'll be creating a new version storage.  I
don't promise that I'll have automatic upgrades for it yet, but I'll
certainly look into it.

Does anyone else have any ideas on simplifying the use of DBICDH?

--
fREW Schmidt
http://blog.afoolishmanifesto.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20130516/ea391ad9/attachment.pgp