Hi,
The problem as I see it is not really with a specific mapping of some
unsigned types to signed types, but with the fact that v.get<...>() throws
when the types don't match exactly, instead of trying to put the value of
the requested field into whatever type the user wants it in (and only
throwing when that's not possible.) The general understanding was that
soci should be changed, I think Mateusz (cc-ed) started writing a design
doc about it.
As long as we keep the current behavior, i.e., force the users to use
specific integral types, I personally think the current mapping is very
sane. The most natural default integral type in C++ is int so it's fairly
obvious that all smaller types, signed or not, should be interpreted as
int. And for unsigned long long there is no choice either because no other
type is large enough to fit all values from unsigned long long. So the
only non-obvious choice was to convert unsigned long to dt_long_long, which
can be justified by consistency with all smaller unsigned types which are
interpreted as a signed value of a larger type. Even if that decision were
concluded wrong (which I don't think it was) it would be hard to change now
since user code may depend on it (if we change the type some user code may
start to throw.)
Thanks,
Aleksander
On Mon, Jul 22, 2013 at 1:38 PM, Daniel Walter <
[email protected]> wrote:
> Hi there,
>
> I am experiencing some annoying problems with type casting in mysql
> backend.
> In my non trivial SQL query I am doing casts for generated columns to
> avoid problems with the type the server sends for each column.
>
> ,CAST(COALESCE((p2e.inserted IS NOT NULL),0) AS UNSIGNED) AS 'exists'
> ,CAST(COALESCE(p2e.active,0) AS UNSIGNED) AS 'active'
> ,CAST(UNIX_TIMESTAMP(COALESCE(p2e.last_full_update,0)) AS UNSIGNED)
> AS 'last_full_update'
> ,CAST(0 AS UNSIGNED) AS already_ordered
>
> The problem is, that these "CAST" columns do not getting the same type
> from server! For example field "exists" and "active" are of type
> MYSQL_TYPE_LONG (unsigned flag set) and "already_ordered" and
> "last_full_update" are of type MYSQL_TYPE_LONGLONG (unsigned flag set).
> So I cant rely on the resulting type of the "CAST" call.
>
> Here are the lines with the problem from statement.cpp in mysql backend:
>
> case FIELD_TYPE_LONG: //MYSQL_TYPE_LONG:
> type = field->flags & UNSIGNED_FLAG ? dt_long_long
> : dt_integer;
> break;
> case FIELD_TYPE_LONGLONG: //MYSQL_TYPE_LONGLONG:
> type = field->flags & UNSIGNED_FLAG ? dt_unsigned_long_long :
> dt_long_long;
> break;
>
>
> The problem shows up if i try to use such a field in my orm mapping. At
> the beginning I used:
>
> p.exists = v.get<long long>("exists", 0);
>
> Which is at least logically wrong. Because i casted the column to
> "UNSIGNED" and the mapping from the MySQL backend returned an signed
> type? But, not matter, this code was working right... until the type
> changed to MYSQL_TYPE_LONGLONG. The maped type was than "unsigned long
> long" and I got the "bad_cast" error.
>
> From the technical and the logical view and if "UNSIGNED_FLAG" is set
> the resulting type should be an unsigned type! In this case the result
> should be "dt_unsigned_long_long".
>
> Is this change valid or are I am missing something there?
>
>
> User versions:
> Linus version is 3.9-1-686-pae #1 SMP Debian 3.9.8-1 i686 GNU/Linux
> MySQL server version is "5.5.28"
> MySQL client version is "14.14 Distrib 5.5.31, for debian-linux-gnu
> (i686) using readline 6.2" (32bit)
> SOCI is latest from git
>
> Mit freundlichen Grüßen / Best Regards,
> Daniel Walter
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> soci-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/soci-users
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
