On Mon, Jul 2, 2012 at 9:22 AM, Vadim Zeitlin <[email protected]> wrote:
> On Sun, 1 Jul 2012 17:47:10 -0700 Pawel Aleksander Fedorynski
> <[email protected]> wrote:
>
> PAF> I do think that it would be a mistake to map INT UNSIGNED to a
> PAF> four-byte signed int, since then we would be corrupting values larger
> PAF> than 2147483647.
>
> I don't think we would be corrupting them. If you write an unsigned to the
> database and read it back as unsigned you should -- and would, with the
> patches I applied locally -- get back exactly the same value.
If you read it back as unsigned, yes, I thought you wanted to convert
it to signed int?
>
> PAF> To answer your question about how existing application code might be
> PAF> affected by these changes, consider the following example:
> PAF>
> PAF> #include <exception>
> PAF> #include <iostream>
> PAF> #include "soci.h"
> PAF> #include "soci-mysql.h"
> PAF>
> PAF> using namespace soci;
> PAF> using namespace std;
> PAF>
> PAF> int main()
> PAF> {
> PAF> session sql(mysql, "db=test user=root");
> PAF>
> PAF> sql << "drop table if exists soci_test";
> PAF> sql << "create table soci_test(val int unsigned)";
> PAF> sql << "insert into soci_test set val = 123";
> PAF> rowset<row> rs = (sql.prepare << "select val from soci_test");
> PAF> for (rowset<row>::const_iterator it = rs.begin(); it != rs.end();
> ++it) {
> PAF> const row& v = *it;
> PAF> try {
> PAF> cout << v.get<long>(0) << endl;
> PAF> } catch (const exception& e) {
> PAF> cout << e.what() << endl;
> PAF> }
> PAF> try {
> PAF> cout << v.get<unsigned long>(0) << endl;
> PAF> } catch (const exception& e) {
> PAF> cout << e.what() << endl;
> PAF> }
> PAF> try {
> PAF> cout << v.get<long long>(0) << endl;
> PAF> } catch (const exception& e) {
> PAF> cout << e.what() << endl;
> PAF> }
> PAF> }
> PAF> }
> PAF>
> PAF> This code prints:
> PAF>
> PAF> std::bad_cast
> PAF> 123
> PAF> std::bad_cast
> PAF>
> PAF> when built against the latest version in git, but before I made the
> PAF> change today it would have printed:
> PAF>
> PAF> std::bad_cast
> PAF> std::bad_cast
> PAF> 123
> PAF>
> PAF> and using soci-3.1.0 (current stable version, before I added support
> PAF> for INT UNSIGNED) it the output is:
> PAF>
> PAF> 123
> PAF> std::bad_cast
> PAF> std::bad_cast
>
> I really don't know what is the desired behaviour here,
Desired behavior IMO would be to perform the conversion between
integer types whenever possible, i.e., none of the three above should
throw. But as it is, the user needs to specify one exact type to make
the conversion happen, and if you take out x_unsigned_long then the
type the user needs to specify will change, i.e., r.get<unsigned long>
will stop working. Doesn't mean we can't do it, I was just answering
your question how can the application code break.
> although all 3
> above ones seem surprising to me (I'd definitely expect it to succeed for
> the first two cases and either succeed or fail for the last one depending
> on whether promotions are used in this API or not).
>
> All I do know is that doing
>
> unsigned x = ... whetever ...;
> sql << "insert into soci_test(val) values (:x)", use(x);
> sql << "select val from soci_test", into(x);
>
> shouldn't throw any exceptions and should preserve the value of x (even if
> it's greater than INT_MAX).
>
> In the current state, this is not the case for ODBC backend because it
> can fail to save a LONGLONG SQL value into a column using INT type.
>
> PAF> I think that's what Neil meant when he wrote that the code is very
> PAF> fragile. I agree with this, we should probably make row::get<> more
> PAF> forgiving.
>
> Perhaps, but I don't see how does having x_unsigned_long (which is, again,
> not used anywhere except SQLite backend anyhow) can help nor how can
> removing it harm this plan.
>
> Maybe I should push my changes out on a separate branch so that you could
> test them and let me know if you find any problems with MySQL?
You can go ahead and make your changes to the main branch as far as I
am concerned, please do let me know when, so that I can test that the
MySQL backend still compiles and works.
Thanks,
Aleksander
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
