Hey,
Let me add my two cents. In the MySQL backend, the type INT UNSIGNED
(four byte unsigned integer) was first mapped to dt_long_long. Which
was consistent with the treatment of other unsigned types, (CHAR,
SHORT and INT24) which were promoted to a signed 4-byte dt_integer,
which seemed like a reasonable thing to do.
But recently, Michael Evdokimov reported a bug which had to do with
the lack of support for BIGINT UNSIGNED (eight byte unsigned integer.)
Since we have no integer type larger than 8 bytes, I had to map
BIGINT UNSIGNED to dt_unsigned_long_long. So then it seemed more
consistent to change the mapping for INT UNSIGNED from dt_long_long to
dt_unsigned. I don't feel strongly about it and if you think
dt_long_long was a better choice I can change that back.
I do think that it would be a mistake to map INT UNSIGNED to a
four-byte signed int, since then we would be corrupting values larger
than 2147483647. I am definitely in favor of using 64-bit ints (ie
long long) instead, if we were to stick with using only signed types
whenever possible.
To answer your question about how existing application code might be
affected by these changes, consider the following example:
#include <exception>
#include <iostream>
#include "soci.h"
#include "soci-mysql.h"
using namespace soci;
using namespace std;
int main()
{
session sql(mysql, "db=test user=root");
sql << "drop table if exists soci_test";
sql << "create table soci_test(val int unsigned)";
sql << "insert into soci_test set val = 123";
rowset<row> rs = (sql.prepare << "select val from soci_test");
for (rowset<row>::const_iterator it = rs.begin(); it != rs.end(); ++it) {
const row& v = *it;
try {
cout << v.get<long>(0) << endl;
} catch (const exception& e) {
cout << e.what() << endl;
}
try {
cout << v.get<unsigned long>(0) << endl;
} catch (const exception& e) {
cout << e.what() << endl;
}
try {
cout << v.get<long long>(0) << endl;
} catch (const exception& e) {
cout << e.what() << endl;
}
}
}
This code prints:
std::bad_cast
123
std::bad_cast
when built against the latest version in git, but before I made the
change today it would have printed:
std::bad_cast
std::bad_cast
123
and using soci-3.1.0 (current stable version, before I added support
for INT UNSIGNED) it the output is:
123
std::bad_cast
std::bad_cast
I think that's what Neil meant when he wrote that the code is very
fragile. I agree with this, we should probably make row::get<> more
forgiving.
Thanks,
Aleksander
On Tue, Jun 19, 2012 at 10:00 AM, Vadim Zeitlin <[email protected]> wrote:
> On Mon, 18 Jun 2012 20:09:43 +0100 Neil Morgenstern
> <[email protected]> wrote:
>
> NM> I don't think you can just rip it out of the code because people may well
> NM> be using code relying on it being there.
>
> It is defined in a private soci-backend.h header, is it really a serious
> concern that some code using undocumented symbols from this header might be
> broken? Moreover, how exactly would it be used anyhow? I don't see any
> non-artificial way to make use of it outside SOCI, do you?
>
> IMHO the only thing that matters is that the code using parameters of
> all primitive types (including unsigned ones) should continue to work and
> this would be the case.
>
> NM> I do remember wishing that in parts the code was less fragile on type and
> NM> we had to modify our code to make it so - actually most of the code was
> NM> using long as the integral type so we essentially allowed it for any
> NM> integral value that could convert to long without overflow.
>
> Well, unsigned long could be converted to long, as I wrote. IMO it's much
> better to represent it in the same way as long at the database level
> instead of using int64 for it.
>
> Anyhow, please let me know how would any existing code be broken by the
> proposed change.
>
> TIA,
> VZ
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
