[odb-users] another test from odb-tests-2.1.1 fails with
Hugo.Mildenberger at web.de
Hugo.Mildenberger at web.de
Wed Feb 6 09:01:00 EST 2013
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:
> 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 ?
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.
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.
More information about the odb-users