<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
Hi devs,<br>
<br>
While working on patron data export (
<a class="moz-txt-link-freetext" href="https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20028">https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20028</a> ), I
was trying to generate a bunch of test data with TestBuilder, and
then compare them to what was returned by DBIx's search().<br>
<br>
Unfortunately I couldn't do this, because most decimals from
DBI/DBIx are returned in a different formatting to what TestBuilder
has. Running an is_deeply() to compare the objects fails with:<br>
<pre class="bz_comment_text" id="comment_text_0"># Structures begin differing at:
# $got->[0]{amount} = '90203.710000' (value returned by DBIx)
# $expected->[0]{amount} = '90203.71' (value in HASHref generated by TestBuilder)</pre>
This is because TestBuilder's _gen_real() forces the formatting to 2
decimal places.<br>
<br>
But there's more - My original idea to solve this issue was by using
"column_info" provided by DBIx, and formatting the value to maximum
decimal places allowed. But even if you follow the column's size
definition, you will notice that there is a different behavior
between data types "float"/"double" and "decimal". If it's a
decimal, it stays in "stringified" format with all those trailing
zeroes, but if it's a float, all the insignificant zeroes are
dropped from the end.<br>
<br>
At some layer lower than DBIx (perhaps DBD::mysql?) there appears to
be some formatting magic. A concrete example of this is when you
have a FLOAT(10,4) and DECIMAL(10,4) columns and store "10.1000" in
both columns, in the end the float becomes 10.1 and the decimal
"10.1000". It's the same result with both DBI and DBIx. However, for
example mariadb-client chooses to format both values as "10.1000".<br>
<br>
My other solution was to reload the row generated by DBIx in
TestBuilder::_storeColumnValues() with
discard_changes/get_from_storage method, but that<br>
1. doesn't work for tables that do not have primary key (e.g.
statistics), see<br>
<font size="-1">DBIx::Class::ResultSource::_pri_cols_or_die():
Operation requires a primary key to be declared on 'Statistic' via
set_primary_key at /home/koha/Koha/t/lib/TestBuilder.pm line 362</font><br>
2. adds some overhead, although only into tests<br>
<br>
I would appreciate some ideas or improvements. I've created a Bug
for this issue, see
<a class="moz-txt-link-freetext" href="https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27630">https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27630</a> .
There is a test to demonstrate the issue, and the previously
mentioned attempts to solve this issue.<br>
<br>
P.S. Somewhat related bug:
<a class="moz-txt-link-freetext" href="https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20621">https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20621</a><br>
<pre class="moz-signature" cols="72">--
Lari Taskula
CEO, Hypernova Oy
PL 16
80101 Joensuu, Finland</pre>
</body>
</html>