File Coverage

blib/lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm
Criterion Covered Total %
statement 3 3 100.0
branch n/a
condition n/a
subroutine 1 1 100.0
pod n/a
total 4 4 100.0


line stmt bran cond sub pod time code
1             package DBIx::Class::DeploymentHandler::HandlesVersioning;
2             $DBIx::Class::DeploymentHandler::HandlesVersioning::VERSION = '0.002233';
3 15     15   10299 use Moose::Role;
  15         15194  
  15         98  
4              
5             # ABSTRACT: Interface for version methods
6              
7             requires 'next_version_set';
8             requires 'previous_version_set';
9              
10             1;
11              
12             # vim: ts=2 sw=2 expandtab
13              
14             __END__
15              
16             =pod
17              
18             =head1 NAME
19              
20             DBIx::Class::DeploymentHandler::HandlesVersioning - Interface for version methods
21              
22             =head1 DESCRIPTION
23              
24             Typically a VersionHandler will take a C<to_version> and yield an iterator of
25             L<version sets|/VERSION SET>.
26              
27             Typically a call to a VersionHandler's L</next_version_set> with a C<db_version>
28             of 1 and a C<to_version> of 5 will iterate over something like the following:
29              
30             [1, 2]
31             [2, 3]
32             [3, 4]
33             [4, 5]
34             undef
35              
36             or maybe just
37              
38             [1, 5]
39             undef
40              
41             Really how the L<version sets|/VERSION SET> are arranged is up to the
42             VersionHandler being used.
43              
44             In some cases users will not want versions to have inherent "previous
45             versions," which is why the version set is an C<ArrayRef>. In those cases the
46             user should opt to returning merely the version that the database is being
47             upgraded to in each step.
48              
49             One idea that has been suggested to me has been to have a form of dependency
50             management of the database "versions." In this case the versions are actually
51             more like features that may or may not be applied. For example, one might
52             start with version 1 and have a feature (version) C<users>.
53              
54             Each feature might require that the database be upgraded to another version
55             first. If one were to implement a system like this, here is how the
56             VersionHandler's L</next_version_set> might look.
57              
58             to_version = "users", db_version = 1
59             [3]
60             [5]
61             ["users"]
62             undef
63              
64             So what just happened there is that C<users> depends on version 5, which depends
65             on version 3, which depends on version 1, which is already installed. To be
66             clear, the reason we use single versions instead of version pairs is because
67             there is no inherent order for this type of database upgraded.
68              
69             =head2 Downgrades
70              
71             For the typical case downgrades should be easy for users to perform and
72             understand. That means that with the first two examples given above we can use
73             the L</previous_version_set> iterator to yield the following:
74              
75             db_version = 5, to_version=1
76             [5, 4]
77             [4, 3]
78             [3, 2]
79             [2, 1]
80             undef
81              
82             or maybe just
83              
84             [5, 1]
85             undef
86              
87             Note that we do not swap the version number order. This allows us to remain
88             consistent in our version set abstraction, since a version set really just
89             describes a version change, and not necessarily a defined progression.
90              
91             =head1 VERSION SET
92              
93             A version set could be defined as:
94              
95             subtype 'Version', as 'Str';
96             subtype 'VersionSet', as 'ArrayRef[Str]';
97              
98             A version set should uniquely identify a migration.
99              
100             =head1 KNOWN IMPLEMENTATIONS
101              
102             =over
103              
104             =item *
105              
106             L<DBIx::Class::DeploymentHandler::VersionHandler::Monotonic>
107              
108             =item *
109              
110             L<DBIx::Class::DeploymentHandler::VersionHandler::DatabaseToSchemaVersions>
111              
112             =item *
113              
114             L<DBIx::Class::DeploymentHandler::VersionHandler::ExplicitVersions>
115              
116             =back
117              
118             =head1 METHODS
119              
120             =head2 next_version_set
121              
122             print 'versions to install: ';
123             while (my $vs = $dh->next_version_set) {
124             print join q(, ), @{$vs}
125             }
126             print qq(\n);
127              
128             Return a L<version set|/VERSION SET> describing each version that needs to be
129             installed to upgrade to C<< $dh->to_version >>.
130              
131             =head2 previous_version_set
132              
133             print 'versions to uninstall: ';
134             while (my $vs = $dh->previous_version_set) {
135             print join q(, ), @{$vs}
136             }
137             print qq(\n);
138              
139             Return a L<version set|/VERSION SET> describing each version that needs to be
140             "installed" to downgrade to C<< $dh->to_version >>.
141              
142             =head1 AUTHOR
143              
144             Arthur Axel "fREW" Schmidt <frioux+cpan@gmail.com>
145              
146             =head1 COPYRIGHT AND LICENSE
147              
148             This software is copyright (c) 2019 by Arthur Axel "fREW" Schmidt.
149              
150             This is free software; you can redistribute it and/or modify it under
151             the same terms as the Perl 5 programming language system itself.
152              
153             =cut