FAQ
On my debian I had a problem storing a my_ulonglong into a
SQLParams... It threw a Lookuptype failure or something like that...
The type was "y".

Storing an ulong isn't an issue.


If there is any other option I can provide you, please tell me so I
can help you more.


Greetings

Search Discussions

  • Warren Young at Apr 13, 2008 at 8:41 pm

    On Apr 13, 2008, at 1:54 PM, Steven Van Ingelgem wrote:
    On my debian I had a problem storing a my_ulonglong into a
    SQLParams... It threw a Lookuptype failure or something like that...
    The type was "y".
    Try upgrading to v3. There was a lot of work on the type handling
    system.
  • Steven Van Ingelgem at Apr 13, 2008 at 9:13 pm
    That was for v3.0.1 & v3.0.0... I didn't test out v3.0.2 yet though.
    I didn't have this failure in the previous version


    Greetings,
    Steven
    On 13/04/2008, Warren Young wrote:
    On Apr 13, 2008, at 1:54 PM, Steven Van Ingelgem wrote:

    On my debian I had a problem storing a my_ulonglong into a
    SQLParams... It threw a Lookuptype failure or something like that...
    The type was "y".
    Try upgrading to v3. There was a lot of work on the type handling system.

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe:
    http://lists.mysql.com/plusplus?unsub=steven@vaningelgem.be
  • Warren Young at Apr 21, 2008 at 2:44 pm

    Steven Van Ingelgem wrote:
    That was for v3.0.1 & v3.0.0...
    Oh. In that case, try switching to one of the new types defined in
    lib/sql_types.h. my_ulonglong is a MySQL specific type, used for its
    own C API, not really something meant to map to the SQL type system.
    Its meaning changes depending on the platform, not a desirable behavior,
    which is probably why I removed support for it.

    If you still feel MySQL++ needs to support something compatible with
    my_ulonglong, I'll need a SQL-oriented justification. The current data
    type handling system is pretty hairy -- less so in 3.x, but still hairy
    -- and adding support to it for every arbitrary data type has to be done
    by hand, increasing the code's hirsuteness. To justify that, I need a
    case where useful SQL can't be done without this type.
  • Steven Van Ingelgem at Apr 21, 2008 at 6:26 pm
    I am/was using it to store bigints in it. At work I was working with
    10 decimals... Which is just too long for an unsigned int. Though they
    could fit in an unsigned long it... Which I did... But a long long
    would come more close to the meaning of a bigint.


    For my case it's solved ;-).

    Greetz
    On 21/04/2008, Warren Young wrote:
    Steven Van Ingelgem wrote:
    That was for v3.0.1 & v3.0.0...
    Oh. In that case, try switching to one of the new types defined in
    lib/sql_types.h. my_ulonglong is a MySQL specific type, used for its own C
    API, not really something meant to map to the SQL type system. Its meaning
    changes depending on the platform, not a desirable behavior, which is
    probably why I removed support for it.

    If you still feel MySQL++ needs to support something compatible with
    my_ulonglong, I'll need a SQL-oriented justification. The current data type
    handling system is pretty hairy -- less so in 3.x, but still hairy -- and
    adding support to it for every arbitrary data type has to be done by hand,
    increasing the code's hirsuteness. To justify that, I need a case where
    useful SQL can't be done without this type.

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe:
    http://lists.mysql.com/plusplus?unsub=steven@vaningelgem.be
  • Warren Young at Apr 21, 2008 at 7:19 pm

    On Apr 21, 2008, at 12:18 PM, Steven Van Ingelgem wrote:

    I am/was using it to store bigints in it.
    So use mysqlpp::sql_bigint. It's just a typedef, and your code
    doesn't have to care what the underlying type is. This is especially
    useful for less well established types like 64-bit integers, since
    there's less agreement on this than for smaller types.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupplusplus @
categoriesmysql
postedApr 13, '08 at 7:55p
activeApr 21, '08 at 7:19p
posts6
users2
websitemysql.com
irc#mysql

People

Translate

site design / logo © 2022 Grokbase