DB-Handy
view release on metacpan or search on metacpan
- 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 )