view release on metacpan or  search on metacpan

lib/DBIO/Manual/Heritage.pod  view on Meta::CPAN

data from files, and batch inserts. Integrated into L<DBIO::Schema>.
The invocation syntax is unchanged:

  $schema->populate([ Users => ... ]);

=head1 NEW CONCEPTS

These features did not exist in DBIx::Class in any form.

=head2 DBIO::ChangeLog - audit trail per Result class

Automatic row-level change tracking. Add to a Result class:

  __PACKAGE__->load_components('ChangeLog');

DBIO creates a companion table C<E<lt>tableE<gt>_changelog> automatically.
By default every column change is recorded (INSERT, UPDATE, DELETE).
Exclude sensitive columns:

  __PACKAGE__->changelog_exclude_columns(qw/ password_hash session_token /);

Changes are stored as JSON. Methods:

  $row->changelog_entries();          # ResultSet of log rows
  $schema->changelog_serialize_changes($hashref);
  $schema->changelog_deserialize_changes($json_str);

PostgreSQL storage can use native C<jsonb> for the changes column.
The version table was renamed from C<dbix_class_schema_versions> to
C<dbio_schema_versions>.

See L<DBIO::ChangeLog> and L<DBIO::ChangeLog::Schema>.

=head2 DBIO::AccessBroker - credential source interface

A storage-agnostic interface for credential lifecycle management. A broker
is a B<CredentialSource>: it supplies the connect info for one backend
identity. It does not route and does not own a host list - read/write
routing and the master/replicant topology belong to L<DBIO::Replicated>.
Pass a broker to C<connect()> in place of a DSN; the storage detects it
and attaches it:

  my $schema = MyApp::Schema->connect(
      DBIO::AccessBroker::Static->new(
          dsn      => $dsn,
          username => $user,
          password => $pass,
      )
  );

The storage calls C<connect_info_for_storage($storage)> on the broker
before each connection. One credential can serve many servers via a
C<< $broker->for_host($host) >> view.

Built-in broker classes:

=over 4

=item L<DBIO::AccessBroker::Static> - single DSN, drop-in replacement

=item L<DBIO::AccessBroker::Vault> - rotating credentials with TTL

=item L<DBIO::AccessBroker::HostBound> - one credential identity pinned to one host

=back

Build a custom broker by subclassing L<DBIO::AccessBroker> and implementing
C<connect_info_for_storage>, C<needs_refresh>, and C<refresh>.

=head2 DBIO::Moo and DBIO::Moose - OO framework bridges

Use Moo or Moose attributes alongside DBIO column accessors in the same
Result, ResultSet, or Schema class.

  package MyApp::Schema::Result::Artist;
  use DBIO::Moo;
  use DBIO::Cake;

  col artistid => serial, auto_inc;
  col name     => varchar(100);
  primary_key 'artistid';

  has display_name => (is => 'lazy');
  sub _build_display_name { 'Artist: ' . $_[0]->name }

  1;

L<DBIO::Moo> and L<DBIO::Moose> wire the framework constructor
(C<FOREIGNBUILDARGS> for Moo, C<BUILDARGS> for Moose) into DBIO's C<new()>
so that DBIO column data is routed correctly and Moo/Moose attributes are
filtered from DBIO's column constructor.

Combinations with Cake and Candy are fully supported. Use
L<DBIO::Cake> with C<use DBIO::Moo> in the same file.

See L<DBIO::Moo> and L<DBIO::Moose>.

=head2 Async storage interface

L<DBIO::Storage::Async> defines a storage-agnostic async interface
(Phase 1 + 2). Queries return C<Future> objects. Two concrete
implementations bypass DBI entirely:

=over 4

=item C<DBIO::PostgreSQL::Async> (C<DBIO-PostgreSQL-Async>) - C<libpq> via
C<EV::Pg>; adds LISTEN/NOTIFY, COPY IN/OUT, and request pipelining.

=item C<DBIO::MySQL::Async> (C<DBIO-MySQL-Async>) - the MariaDB client via
C<EV::MariaDB>; adds pipelining and connection-pool transaction pinning.

=back

The core async interface is in C<DBIO::Storage::Async>. Application code
that targets multiple backends should program against that interface.

=head2 Type registry on Storage

Each driver's Storage class exposes:

  $schema->storage->cake_defaults()        # hashref of driver-preferred options