view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    unexpected magical things happen, like hash fields that populate
    themselves. The magic is only there to make matching the File::KeePass
    interface possible, since that interface assumes some amount of
    interaction with unblessed data structures. Some effort was made to at
    least hide the magic where reasonable; any magical behavior is
    incidental and not considered a feature.

    You should expect some considerable overhead which makes this module
    generally slower than using either File::KeePass or File::KDBX
    directly. In some cases this might be due to an inefficient
    implementation in the shim, but largely it is the cost of transparent
    compatibility.

    If performance is critical and you still don't want to rewrite your
    code to use File::KDBX directly but do want to take advantage of some
    of the new stuff, there is also the option to go part way. The strategy
    here is to use File::KeePass::KDBX to load a database and then
    immediately convert it to a File::KeePass object. Use that object
    without any runtime overhead, and then if and when you're ready to save
    the database or use any other File::KDBX feature, "upgrade" it back
    into a File::KeePass::KDBX object. This strategy would require modest

lib/File/KeePass/KDBX.pm  view on Meta::CPAN

=head1 CAVEATS

This shim uses L<perltie> magics. Some data structures look and act like regular hashes and arrays (mostly),
but you might notice some unexpected magical things happen, like hash fields that populate themselves. The
magic is only there to make matching the B<File::KeePass> interface possible, since that interface assumes
some amount of interaction with unblessed data structures. Some effort was made to at least hide the magic
where reasonable; any magical behavior is incidental and not considered a feature.

You should expect some considerable overhead which makes this module generally slower than using either
B<File::KeePass> or B<File::KDBX> directly. In some cases this might be due to an inefficient implementation
in the shim, but largely it is the cost of transparent compatibility.

If performance is critical and you still don't want to rewrite your code to use B<File::KDBX> directly but do
want to take advantage of some of the new stuff, there is also the option to go part way. The strategy here is
to use B<File::KeePass::KDBX> to load a database and then immediately convert it to a B<File::KeePass> object.
Use that object without any runtime overhead, and then if and when you're ready to save the database or use
any other B<File::KDBX> feature, "upgrade" it back into a B<File::KeePass::KDBX> object. This strategy would
require modest code modifications to your application, to change:

    my $k = File::KeePass->new('database.kdbx', 'masterpw');