NAME¶
DBIx::Class::DeploymentHandler::HandlesVersioning - Interface for version
methods
DESCRIPTION¶
Typically a VersionHandler will take a "to_version" and yeild an
iterator of version sets.
Typically a call to a VersionHandler's "next_version_set" with a
"db_version" of 1 and a "to_version" of 5 will iterate
over something like the following:
[1, 2]
[2, 3]
[3, 4]
[4, 5]
undef
or maybe just
[1, 5]
undef
Really how the version sets are arranged is up to the VersionHandler being used.
In some cases users will not want versions to have inherent "previous
versions," which is why the version set is an "ArrayRef". In
those cases the user should opt to returning merely the version that the
database is being upgraded to in each step.
One idea that has been suggested to me has been to have a form of dependency
management of the database "versions." In this case the versions are
actually more like features that may or may not be applied. For example, one
might start with version 1 and have a feature (version) "users".
Each feature might require that the database be upgraded to another version
first. If one were to implement a system like this, here is how the
VersionHandler's "next_version_set" might look.
to_version = "users", db_version = 1
[3]
[5]
["users"]
undef
So what just happened there is that "users" depends on version 5,
which depends on version 3, which depends on version 1, which is already
installed. To be clear, the reason we use single versions instead of version
pairs is because there is no inherent order for this type of database
upgraded.
Downgrades¶
For the typical case downgrades should be easy for users to perform and
understand. That means that with the first two examples given above we can use
the "previous_version_set" iterator to yeild the following:
db_version = 5, to_version=1
[5, 4]
[4, 3]
[3, 2]
[2, 1]
undef
or maybe just
[5, 1]
undef
Note that we do not swap the version number order. This allows us to remain
consistent in our version set abstraction, since a version set really just
describes a version change, and not necesarily a defined progression.
VERSION SET¶
A version set could be defined as:
subtype 'Version', as 'Str';
subtype 'VersionSet', as 'ArrayRef[Str]';
A version set should uniquely identify a migration.
KNOWN IMPLEMENTATIONS¶
- •
- DBIx::Class::DeploymentHandler::VersionHandler::Monotonic
- •
- DBIx::Class::DeploymentHandler::VersionHandler::DatabaseToSchemaVersions
- •
- DBIx::Class::DeploymentHandler::VersionHandler::ExplicitVersions
METHODS¶
next_version_set¶
print 'versions to install: ';
while (my $vs = $dh->next_version_set) {
print join q(, ), @{$vs}
}
print qq(\n);
Return a version set describing each version that needs to be installed to
upgrade to "$dh->to_version".
previous_version_set¶
print 'versions to uninstall: ';
while (my $vs = $dh->previous_version_set) {
print join q(, ), @{$vs}
}
print qq(\n);
Return a version set describing each version that needs to be
"installed" to downgrade to "$dh->to_version".
AUTHOR¶
Arthur Axel "fREW" Schmidt <frioux+cpan@gmail.com>
COPYRIGHT AND LICENSE¶
This software is copyright (c) 2014 by Arthur Axel "fREW" Schmidt.
This is free software; you can redistribute it and/or modify it under the same
terms as the Perl 5 programming language system itself.