DBIO

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

        - Remove warning about potential side effects of RT#79576 (scheduled)
        - Various doc improvements (GH#35, GH#62, GH#66, GH#70, GH#71, GH#72)
        - Depend on newer Moo, to benefit from a safer runtime (RT#93004)
        - Fix intermittent failures in the LeakTracer on 5.18+
        - Fix failures of t/54taint.t on Windows with spaces in the $^X
          executable path (RT#101615)

0.082810 2014-10-25 13:58 (UTC)
    * Fixes
        - Fix incorrect collapsing-parser source being generated in the
          presence of unicode data among the collapse-points
        - Fix endless loop on BareSourcelessResultClass->throw_exception(...)

    * Misc
        - Depend on newer SQL::Abstract (fixing overly-aggressive parenthesis
          opener: RT#99503)
        - Depend on newer Moo, fixing some interoperability issues:
          http://lists.scsys.co.uk/pipermail/dbix-class/2014-October/011787.html

0.082801 2014-10-05 23:55 (UTC)
    * Known Issues

Changes  view on Meta::CPAN

        - Fix inability to handle multiple consecutive transactions with
          savepoints on DBD::SQLite < 1.39
        - Fix CDBICompat to match Class::DBI behavior handling non-result
          blessed has_a (implicit deflate via stringification and inflate via
          blind new) (GH#51)

    * Misc
        - Ensure source metadata calls always take place on the result source
          instance registered with the caller
        - IFF DBIC_TRACE output defaults to STDERR we now silence the possible
          wide-char warnings if the trace happens to contain unicode

0.08270 2014-01-30 21:54 (PST)
    * Fixes
        - Fix 0.08260 regression in DBD::SQLite bound int handling. Inserted
          data was not affected, but any function <=> integer comparison would
          have failed (originally fixed way back in 0e773352)
        - Fix failure to load DateTime formatter when connecting to Firebird
          over ODBC

    * Misc

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


This kludge is necessary only for conditions passed to
L<search|DBIO::ResultSet/search> and L<DBIO::ResultSet/find>,
whereas L<create|DBIO::ResultSet/create> and
L<DBIO::Row/update> (but not L<DBIO::ResultSet/update>) are
L<DBIO::InflateColumn>-aware and will do the right thing when supplied
an inflated L<DateTime> object.

=head2 Using Unicode

When using unicode character data there are two alternatives -
either your database supports unicode characters (including setting
the utf8 flag on the returned string), or you need to encode/decode
data appropriately each time a string field is inserted into or
retrieved from the database. It is better to avoid
encoding/decoding data and to use your database's own unicode
capabilities if at all possible.

Most modern databases handle Unicode natively. Ensure your database
connection is configured for UTF-8 (e.g. C<pg_enable_utf8> for
PostgreSQL, C<mysql_enable_utf8mb4> for MySQL).

The following databases do correctly handle unicode data:-

=head3 MySQL

MySQL supports unicode, and will correctly flag utf8 data from the
database if the C<mysql_enable_utf8> is set in the connect options.

  my $schema = My::Schema->connection('dbi:mysql:dbname=test',
                                      $user, $pass,
                                      { mysql_enable_utf8 => 1} );

When set, a data retrieved from a textual column type (char,
varchar, etc) will have the UTF-8 flag turned on if necessary. This
enables character semantics on that string. You will also need to
ensure that your database / table / column is configured to use
UTF8. See Chapter 10 of the mysql manual for details.

See L<DBD::mysql> for further details.

=head3 Oracle

Information about Oracle support for unicode can be found in
L<DBD::Oracle/UNICODE>.

=head3 PostgreSQL

PostgreSQL supports unicode if the character set is correctly set
at database creation time. Additionally the C<pg_enable_utf8>
should be set to ensure unicode data is correctly marked.

  my $schema = My::Schema->connection('dbi:Pg:dbname=test',
                                      $user, $pass,
                                      { pg_enable_utf8 => 1} );

Further information can be found in L<DBD::Pg>.

=head3 SQLite

SQLite version 3 and above natively use unicode internally. To
correctly mark unicode strings taken from the database, the
C<sqlite_unicode> flag should be set at connect time (in versions
of L<DBD::SQLite> prior to 1.27 this attribute was named
C<unicode>).

  my $schema = My::Schema->connection('dbi:SQLite:/tmp/test.db',
                                      '', '',
                                      { sqlite_unicode => 1} );

=head1 BOOTSTRAPPING/MIGRATING

=head2 Easy migration from class-based to schema-based setup

You want to start using the schema-based approach to L<DBIO>
(see L<DBIO::Manual::Intro/Setting it up manually>), but have an
established class-based setup with lots of existing classes that you don't
want to move by hand. Try this nifty script instead:

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

  ) {
    $self->_populate_dbh;
    $drv = $self->_dbh->{Driver}{Name};
  }
  else {
    # try to use dsn to not require being connected, the driver may still
    # force a connection later in _rebless to determine version
    # (dsn may not be supplied at all if all we do is make a mock-schema)
    #
    # Use the same regex as the one used by DBI itself (even if the use of
    # \w is odd given unicode):
    # https://metacpan.org/source/TIMB/DBI-1.634/DBI.pm#L621
    #
    # DO NOT use https://metacpan.org/source/TIMB/DBI-1.634/DBI.pm#L559-566
    # as there is a long-standing precedent of not loading DBI.pm until the
    # very moment we are actually connecting
    #
    ($drv) = ($self->_dbi_connect_info->[0] || '') =~ /^dbi:(\w*)/i;
    $drv ||= $ENV{DBI_DRIVER};
  }

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

      if ($data_type =~ /^(?:
          l? (?:var)? char(?:acter)? (?:\s*varying)?
            |
          (?:var)? binary (?:\s*varying)?
            |
          raw
        )\b/x
      ) {
        $max_size = $attr->{sqlt_size};
      }
      # Other charset/unicode types, assume scale of 4
      elsif ($data_type =~ /^(?:
          national \s* character (?:\s*varying)?
            |
          nchar
            |
          univarchar
            |
          nvarchar
        )\b/x
      ) {

t/resultset/rowparser_internals.t  view on Meta::CPAN

    $#{$_[0]} = $result_pos - 1;
  ',
  'Multiple has_many on multiple branches with underdefined root, HRI-direct torture test',
);

done_testing;

my $deparser;
sub is_same_src { SKIP: {

  skip "Skipping comparison of unicode-posioned source", 1
    if DBIO::Util::stresstest_utf8_upgrade_generated_collapser_source();

  $deparser ||= B::Deparse->new;
  local $Test::Builder::Level = $Test::Builder::Level + 1;

  my ($got, $expect) = @_;

  skip "Not testing equality of source containing defined-or operator on this perl $]", 1
    if ($] < 5.010 and$expect =~ m!\Q//=!);

xt/authors.t  view on Meta::CPAN

use strict;

use Test::More;
use Config;
use File::Spec;

my @known_authors;
my @sections; # array of arrayrefs, one per section

do {
  # according to #p5p this is how one safely reads random unicode
  # this set of boilerplate is insane... wasn't perl unicode-king...?
  no warnings 'once';
  require Encode;
  require PerlIO::encoding;
  local $PerlIO::encoding::fallback = Encode::FB_CROAK();

  open (my $fh, '<:encoding(UTF-8)', 'AUTHORS') or die "Unable to open AUTHORS - can't happen: $!\n";
  my @current_section;
  my $in_header = 1;
  while (<$fh>) {
    chomp;



( run in 1.144 second using v1.01-cache-2.11-cpan-9581c071862 )