DB-Handy

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

  - lib/DB/Handy.pm, README: DIAGNOSTICS said that the error variables
    are "set on every failed operation and cleared on success".  That
    holds for $dbh->errstr and $sth->errstr but not for the
    package-level $DB::Handy::errstr, which is only ever overwritten by
    the next error and so still holds a stale message after a success.
    Both now say so and point at the handle accessor instead.
  - eg/crud_sample.pl: the script leaves ./sample_db behind on purpose,
    so that eg/db_dump.pl has something to read, but said nothing about
    it.  The header comment now explains this and the closing message
    gives the db_dump.pl command line and the one-liner that removes the
    directory.
  - Contact address changed from ina@cpan.org to ina.cpan@gmail.com
    throughout lib/DB/Handy.pm, README, Makefile.PL, META.yml,
    META.json and SECURITY.md.
  - lib/DB/Handy.pm: POD =head1 VERSION corrected from "Version 1.07"
    to "Version 1.09" (was not updated at the 1.08 release).
  - lib/DB/Handy.pm: the Subqueries section documents what the outer
    query of a derived table accepts, including aggregates and the
    order in which LIMIT is applied.  The feature list notes that
    whitespace inside a quoted value is preserved.  =head1 ATTRIBUTES
    documents AutoCommit, which is no longer listed as unimplemented.
  - lib/DB/Handy.pm: =head1 DATA TYPES describes the INT range check
    and the DATE validity rules, and no longer claims that no date
    validation is performed.  The FLOAT entry now distinguishes the
    order-preserving encoding used for index keys from the native
    double written to the .dat file.
  - lib/DB/Handy.pm: corrected seven POD passages that described the
    array-ref column order as alphabetical.  It is the SELECT list
    order for a named column list and the CREATE TABLE declaration
    order for SELECT * (qualified, table by table, for a JOIN); the
    =head2 NAME entry already said so, so the POD contradicted itself.
  - lib/DB/Handy.pm: fetchall_arrayref documents that a column-index
    slice such as [0, 2] is ignored and every column is returned.
  - lib/DB/Handy.pm: DBI COMPATIBILITY and =head1 ATTRIBUTES list the
    new NAME_lc / NAME_uc / NUM_OF_PARAMS / Statement attributes, and
    Statement is no longer listed as unimplemented.
  - lib/DB/Handy.pm: =head1 BUGS AND LIMITATIONS gains three entries:
    declared column sizes count bytes rather than characters (a
    VARCHAR(10) holds three UTF-8 Japanese characters, not ten); a
    trailing NUL byte in a value is stripped when the record is read
    back; and an unterminated /* comments out the rest of the
    statement instead of raising a syntax error.
  - lib/DB/Handy.pm: =head1 BUGS AND LIMITATIONS documents five
    behaviours that were previously undocumented: NULL is stored as the
    empty string and is indistinguishable from 0 in an INT or FLOAT
    column; SUM/AVG/MIN/MAX return 0 rather than NULL over an empty
    set; LIKE is case-insensitive; an unknown column name yields NULL
    instead of an error; and FLOAT values in the .dat file use the
    machine's native double, so a data file holding FLOAT columns is
    not portable between machines with different byte order.  The
    FLOAT-on-disk format is deliberately left unchanged so that data
    files written by 1.08 and earlier stay readable.
  - lib/DB/Handy.pm: the File locking bullet in =head1 DESCRIPTION no
    longer calls concurrent access "safe".  It now says that a lock is
    held for the duration of every read and write, that this serialises
    access on a local file system, and that the return value of flock()
    is not checked, with a link to =head1 BUGS AND LIMITATIONS.
  - lib/DB/Handy.pm: =head1 BUGS AND LIMITATIONS gains an entry for the
    unchecked flock() return value: where locking is unavailable (NFS
    with no lock daemon, some network shares) the call fails silently
    and the access proceeds unlocked, so a single writer should be
    assumed there.  The failure is ignored deliberately, since raising
    an error would make the module unusable on those file systems.
  - lib/DB/Handy.pm: the "Value too long" error now reads "declared
    VARCHAR(5), got 10 bytes" instead of "declared VARCHAR(5) bytes,
    got 10 bytes", which stated the unit twice, and it names the type
    the column was actually declared with.  The check covers CHAR as
    well as VARCHAR, but the message said VARCHAR for both, so a CHAR(3)
    violation was reported as "declared VARCHAR(3)".
  - lib/DB/Handy.pm: FLOAT now applies the same non-numeric test that
    INT has applied since earlier in this release, and applies it on
    both the record path (_pack_record) and the index key path
    (_encode_key).  Up to 1.08 the FLOAT branches handed the raw value
    to pack(), so storing a value that was not a number leaked an
    "isn't numeric" warning out of the module -- twice per row when the
    column was indexed, and once more when such a column was compared
    in a WHERE clause.  The module sets $^W itself, so the warning
    appeared whatever the caller's own warning settings were.  The two
    types also disagreed about what a value like '12abc' meant: INT
    failed the test and stored 0, while FLOAT let Perl stop at the
    first non-digit and stored 12.  Both store 0 now.  Values that
    really are numbers are unaffected: '1e3', ' 42 ' and -2.5 still
    round trip, and an index lookup on a FLOAT column still works.
  - lib/DB/Handy.pm: the numeric test itself was written out three
    times (index key encoding, type validation, record packing) and is
    now the single function _looks_numeric().  Three copies of one
    regular expression is how the FLOAT paths came to have no copy at
    all, and it is the same trap that produced three copies of the LIKE
    implementation.
  - lib/DB/Handy.pm: =head1 DATA TYPES documents the FLOAT rule.  The
    INT entry said what happens to a value that is not numeric; the
    FLOAT entry said nothing.
  - t/1019_types.t: new group T7 covers the FLOAT rule -- no warning on
    insert, on an indexed insert, on update or on comparison; the value
    stored is 0; INT and FLOAT agree about '12abc'; genuine numbers
    still round trip; and both index lookups still find their rows.
    Seven of the fourteen new assertions fail against 1.09 as first
    built.

  Documentation:
  - lib/DB/Handy.pm: =head1 BUGS AND LIMITATIONS records that a
    single-table WHERE clause is not syntax-checked.  The JOIN parser
    added in this release rejects a condition it cannot read, but the
    single-table parser still treats one as matching nothing, so
    "WHERE x = 1 GARBAGE", "WHERE x ==== 1", "WHERE x = 1 AND" and
    "WHERE (x = 1" all return zero rows rather than reporting a syntax
    error.  DELETE and UPDATE fail safe -- an unreadable condition
    changes and removes nothing -- but a SELECT gives a plausible empty
    answer to a question it never asked.  This is the same class of
    fault the JOIN work removed, left in place here because rejecting
    an unreadable single-table condition would change the result of
    existing queries; it is documented rather than silently carried.

  Build tool:
  - pmake.bat 0.44: files in the generated archive are 0644, and .pl,
    .bat, .exe, .com and bin/* are 0755.  0664 and 0775 marked every
    file group-writable, which is not the CPAN convention.
  - pmake.bat 0.44: 'perl' is no longer written into PREREQ_PM in the
    generated Makefile.PL.  MIN_PERL_VERSION already carries it, and
    older ExtUtils::MakeMaker reports a missing prerequisite named
    "perl" when it appears in both.  The META files still list it



( run in 0.923 second using v1.01-cache-2.11-cpan-800906f7e73 )