[odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a

[Hugo.Mildenberger at web.de]

Hi Boris


 Boris Kolpackov <boris at codesynthesis.com> wrote:

 > > A minimal test case would be useful for a upstream bug report anyway.
 > 
 > The test case is attached.
 
I did not receive any attachment.
 

 > Ah, I didn't realize they re-implemented the client library. That would
 > explain all the test failures.

No. Your post regarding this issue overlapped with an intermediate post 
I sent when I discovered what happened. In case it did not reach you, here 
it is again:

   I'm sorry, but this result was a false positive. The patch set actually does 
   not fix the MariaDB problem. After a system reboot the original error reappeared, 
   affecting both tests in boost/mysql/date-time and qt/mysql/date-time. The 
   fix (and other symptoms) were obviously caused by the MariaDB native client 
   library which somehow survived it's deletion. Except for a caching issue 
   I have no idea why this happened. 

The native client is a separate project. I used the bzr development version in a 
hitherto fruitless attempt to isolate the reason for the datetime issue. And tried
that only days after I had sent the first report regarding the datetime issue to
the odb mailing list.


 > > By the way, I've observed that within the structure "st_mysql_time" the
 > > field "time_type" is also not initialized by odb. Although the 
 > > documentation officially states that callers of mysql_stmt_bind_param
 > > may leave this field unassigned, one can not know if all developers 
 > > who eventually become involved will remember this statement.
 > 
 > Where do you see this? The only documentation for MYSQL_TIME that I
 > know is here:
 > 
 > http://dev.mysql.com/doc/refman/5.5/en/c-api-prepared-statement-data-structures.html
 > 
 > And it doesn't say anything about time_type (nor st_mysql_time, for
 > that matter).

I also can't find it for the moment. Maybe it was from sources ?

mariadb-5.5.28a/mariadb-5.5.28a/libmysql.c:

 2740     Binding dates and times.
 2741       For binding dates and times prepared statements API provides
 2742       clients with MYSQL_TIME structure. A pointer to instance of this
 2743       structure should be assigned to MYSQL_BIND::buffer whenever
 2744       MYSQL_TYPE_TIME, MYSQL_TYPE_DATE, MYSQL_TYPE_DATETIME typecodes
 2745       are used.  When typecode is MYSQL_TYPE_TIME, only members
 2746       'hour', 'minute', 'second' and 'neg' (is time offset negative)
 2747       are used. These members only will be sent to the server.
 2748       MYSQL_TYPE_DATE implies use of 'year', 'month', 'day', 'neg'.
 2749       MYSQL_TYPE_DATETIME utilizes both parts of MYSQL_TIME structure.
 2750       You don't have to set MYSQL_TIME::time_type member: it's not
 2751       used when sending data to the server, typecode information is
 2752       enough.  'second_part' member can hold microsecond precision of
 2753       time value, but now it's only supported on protocol level: you
 2754       can't store microsecond in a column, or use in temporal
 2755       calculations. However, if you send a time value with microsecond
 2756       part for 'SELECT ?', statement, you'll get it back unchanged
 2757       from the server.
 2758 
 2759     Data conversion.
 2760       If conversion from host language type to data representation,
 2761       corresponding to SQL type, is required it's done on the server.
 2762       Data truncation is possible when conversion is lossy. For
 2763       example, if you supply MYSQL_TYPE_DATETIME value out of valid
 2764       SQL type TIMESTAMP range, the same conversion will be applied as
 2765       if this value would have been sent as string in the old
 2766       protocol.  TODO: document how the server will behave in case of
 2767       truncation/data loss. 




Hugo