DBIO

 view release on metacpan or  search on metacpan

docs/adr/0006-native-deploy-owns-sql-generation.md  view on Meta::CPAN

migration of ADR 0007 needs — the diff layer compares *introspected* models, so
the deployer that fills a scratch database must be native too). Demoting SQLT to
optional drops a hard dependency from every deploying app and stops bounding DDL
quality by SQLT's producers.

Heritage.pod records the intent (`lib/DBIO/Manual/Heritage.pod:117-126`): "Every
driver ships its own native Deploy, Introspect, and Diff modules … so
SQL::Translator is an optional dependency rather than a required one."

**Flag — code is stricter than the prose.** Heritage says `deploy()` "falls back
to the L<SQL::Translator> path transparently." Core ships no such fallback: the
`deployment_statements` path on `Storage::DBI` *throws* when no DDL file and no
native Deploy class is present (`Storage/DBI.pm:3160-3162`), and
`DeployMethod::Native` *throws* when it cannot resolve a native Deploy class
(`Native.pm:73-78`). The "transparent SQLT fallback" is a property a driver may
choose to provide, not something core implements. The ADR records what the code
does: native-or-throw, SQLT optional and unused by core's own deploy path.

## Consequences

- DDL generation is a driver concern. Each driver ships `Deploy`, `Introspect`
  and `Diff` modules; core ships only the shared bases
  (`DBIO::Deploy::Base`, `DBIO::Deploy::Base::TempDatabase`) and the routing
  `DeployMethod::Native`.
- `deployment_statements()` is no longer a SQL generator — it is a DDL-file

lib/DBIO/Cake.pm  view on Meta::CPAN

=head2 idx

  idx name_idx => ['name'];
  idx composite_idx => ['last_name', 'first_name'], type => 'unique';
  idx tags_idx => ['tags'], using => 'gin';
  idx draft_only => ['key'],
      type => 'unique',
      pg   => { where => 'version IS NULL' };

Declares an index. Cake installs two hooks on the Result class so that
C<idx> works transparently in both deployment pipelines:

=over

=item * C<sqlt_deploy_hook> — B<DEPRECATED> hook for legacy
deployment. The C<options> key passes producer-specific options through.

=item * C<pg_indexes> — used by L<DBIO::PostgreSQL::DDL> when the schema
loads the C<PostgreSQL> component. The C<pg> key carries
PostgreSQL-specific options (C<where>, C<using>, C<with>, C<expression>)
and is passed through to the native PG DDL emitter.

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

  # Now returns the correct new value:
  $result->somecolumn()

To update and refresh at once, chain your calls:

  $result->update({ 'somecolumn' => { -ident => 'othercolumn' } })->discard_changes;

=item .. store JSON/YAML in a column and have it deflate/inflate automatically?

You can use L<DBIO::InflateColumn> to accomplish YAML/JSON storage transparently.

If you want to use JSON, then in your table schema class, do the following:

 use JSON;

 __PACKAGE__->add_columns(qw/ ... my_column ../)
 __PACKAGE__->inflate_column('my_column', {
     inflate => sub { jsonToObj(shift) },
     deflate => sub { objToJson(shift) },
 });

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

      password => {
          data_type       => 'varchar',
          size            => 100,
          encode_column   => 1,
          encode_class    => 'Digest',
          encode_args     => { algorithm => 'SHA-256', format => 'hex' },
          encode_check_method => 'check_password',
      },
  );

The column is encoded transparently on write. The C<check_password>
(or whatever name you give C<encode_check_method>) method is generated
automatically on the Result class.

Storage format: C<dbio$E<lt>algoE<gt>$E<lt>salt_b64E<gt>$E<lt>digest_b64E<gt>>.

See L<DBIO::EncodedColumn>.

=head2 DBIO::HashAccessor

Accessor generation for serialized hash columns (JSON, YAML, MessagePack):

lib/DBIO/ResultSet.pm  view on Meta::CPAN

To create one row for this resultset, pass a hashref of key/value
pairs representing the columns of the table and the values you wish to
store. If the appropriate relationships are set up, foreign key fields
can also be passed an object representing the foreign row, and the
value will be set to its primary key.

To create related objects, pass a hashref of related-object column values
B<keyed on the relationship name>. If the relationship is of type C<multi>
(L<DBIO::Relationship/has_many>) - pass an arrayref of hashrefs.
The process will correctly identify columns holding foreign keys, and will
transparently populate them from the keys of the corresponding relation.
This can be applied recursively, and will work correctly for a structure
with an arbitrary depth and width, as long as the relationships actually
exists and the correct column data has been supplied.

Instead of hashrefs of plain related data (key/value pairs), you may
also pass new or inserted objects. New objects (not inserted yet, see
L</new_result>), will be inserted into their appropriate tables.

Effectively a shortcut for C<< ->new_result(\%col_data)->insert >>.

lib/DBIO/Row.pm  view on Meta::CPAN

innermost being the first declared). If any registered arg has
C<< txn_wrap => 1 >> the whole update is wrapped in a
C<txn_scope_guard>.

See L<DBIx::Class::Helper::Row::OnColumnChange/on_column_change_allow_override_args>
for C<on_column_change_allow_override_args> semantics.

=head2 ProxyResultSetMethod

Expose a C<with_foo> ResultSet method as a row accessor with a
transparent fallback: if the column was already selected via the
ResultSet method it is returned from the cached row data; otherwise
the ResultSet method is re-run for this row.

  package MyApp::Schema::ResultSet::Foo;
  sub with_friend_count { ... }

  package MyApp::Schema::Result::Foo;
  __PACKAGE__->proxy_resultset_method('friend_count');

  $foo_rs->first->friend_count;           # lazy fetch

lib/DBIO/Storage/DBI/ODBC.pm  view on Meta::CPAN

DBIO::Storage::DBI::ODBC - Base class for ODBC drivers

=head1 VERSION

version 0.900000

=head1 DESCRIPTION

This class simply provides a mechanism for discovering and loading a sub-class
for a specific ODBC backend.  It should be transparent to the user.

=head1 METHODS

=head2 _rebless

Resolve and rebless into a backend-specific ODBC storage subclass.

=head2 _using_freetds

Return true when current connection appears to use FreeTDS.