I've just released KiokuDB version 0.37, which introduces class versioning.
This feature is disabled by default to avoid introducing errors to existing schemas[1]. To try it out pass check_class_versions => 1 to connect:
KiokuDB->connect( dsn => ..., check_class_versions => 1, );
To use this feature, whenever you make an incompatible change to a class, also change the $VERSION. When KiokuDB tries to load an object that has been stored before the change was made, the version mismatch is detected (versions are only compared as strings, there is no meaning to the values).
Without any configuration this mismatch will result in an error at load time, but the KiokuDB::Role::Upgrade::Handlers::Table role allows you to declaratively add upgrade handlers to your classes:
package Foo; use Moose; with qw(KiokuDB::Role::Upgrade::Handlers::Table); use constant kiokudb_upgrade_handlers_table => { # we can mark versions as being equivalent in terms of their # data. 0.01 to 0.02 may have introduced an incompatible API # change, but the stored data should be compatible "0.01" => "0.02", # on the other hand, after 0.02 there may have been an # incompatible data change, so we need to convert "0.02" => sub { my ( $self, %args ) = @_; return $args{entry}->derive( class_version => our $VERSION, # up to date version data => ..., # converted entry data ); }, };
For more details see the documentation, especially KiokuDB::TypeMap::Entry::MOP.
[1] In the future this might be enabled by default, but when data without any version information is found in the database it is assumed to be up to date.
1 comment:
Kickass!!
Post a Comment