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 |