GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  DBIX::CLASS::DEPLOYMENTHANDLER::HANDLESVERSIONING (3)

.ds Aq ’

NAME

DBIx::Class::DeploymentHandler::HandlesVersioning - Interface for version methods

CONTENTS

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

o DBIx::Class::DeploymentHandler::VersionHandler::Monotonic
o DBIx::Class::DeploymentHandler::VersionHandler::DatabaseToSchemaVersions
o 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) 2015 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.

Search for    or go to Top of page |  Section 3 |  Main Index


perl v5.20.3 DBIX::CLASS::DEPLOYMENTHANDLER::HANDLESVERSIONING (3) 2015-06-14

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.