Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Schema API supports unsigned integers, but Database API does not allow inserting/updating unsigned integers.
I think it's because there's %u placeholder. Any chance to get this fixed for D6?
Please note that one could workaround this building the SQL statement by hand, but this is not an option when using a CCK field that implements an unsigned integer because CCK uses db_type_placeholder(). If %u was added in D6, then CCK would have to be fixed as well (to use db_type_placeholder properly for unsigneds).
Comments
Comment #1
markus_petrux CreditAttribution: markus_petrux commentedOops! typo: I tried to mean "there's NOT %u placeholder".
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedPHP does not support unsigned integers. What exactly do you want to do?
Comment #3
markus_petrux CreditAttribution: markus_petrux commentedInteger size in PHP is platform dependent, which means DB unsigned ints are supported by PHP on x64 CPUs. But on x32 CPUs, numbers beyond builtin integer bounds are interpreted as a float instead, so you can still use 4294967295 + 1.
Please, test the following on x32:
When using %d for an unsigned int in db_query(), 4294967295 is converted to -1 by the %d placeholder, and updating a INT UNSIGNED field in the DB with -1 you get 0. :(
But, if we could use %u, then it would work. :)
Example of what we need:
We also need to support unsigned integers for this:
http://drupal.org/project/formatted_number
Comment #4
markus_petrux CreditAttribution: markus_petrux commentedPlease note that Schema API supports unsigned integers, and even supports bigint and unsigned bigint, but ....how do you insert data into such fields?
bigint support is much more complex, because it might be necessary to use BCMath/GMP extensions. That's another war I would not like to mix here.
But... support for unsigned integers? Please, consider adding this to D6. Otherwise we are restricted to -2147483648 / 2147483647 with both PHP and DB Layers able to deal with bigger numbers.
Comment #5
Chris Charltonsubscribing.
Comment #6
Damien Tournoud CreditAttribution: Damien Tournoud commentedOk, we should replace:
by
Right?
As a side note, the %d modifier is the dumbest modifier ever.
sprintf("%d", 4294967295) == "-1"
? Come on, PHP is supposed to be loosely typed!Comment #7
phpdiva CreditAttribution: phpdiva commentedRan into the bigint issue while using drupal_write_record().
Apparently the problem lies in db_type_placeholder() function, which uses '%d' as the placeholder for all 'int' type columns, regardless of size.
Comment #8
adzio CreditAttribution: adzio commentedI am, too, affected by the discrepancy between the ability to create 'unsigned int' columns in the db and the absence of the '%u' modifier equivalent in database.inc.
Substituting the int cast with round() is far from ideal, because of how the result of round() depends on the fraction (clearly seen in the examples in the php manual) and PHP_ROUND_HALF_DOWN is not implemented in versions of PHP earlier than 5.3. Also, augmenting the '%d' modifier in database.inc is also not advisable as this would constitute a departure from the printf convention which seems to be followed here, where '%d' signifies a signed integer. Both approaches could potentially break existing code that universally relies on those modifiers returning expected values within their appropriate ranges.
Comment #9
eaton CreditAttribution: eaton commentedJust ran into this due to Twitter module's issues with the number of total twitter statuses rolling over the signed int limit. To reiterate: we must do one of the following:
Currently, we're giving developers a data type that amounts to a trap.
Comment #10
Dave ReidYikes. Subscribing.
Comment #11
mikeytown2 CreditAttribution: mikeytown2 commentedI would opt for option 1.
http://api.drupal.org/api/function/db_type_placeholder
http://drupal.org/node/159605
Pass the size variable.
I don't see an easy way to handle unsigned ints right now.
EDIT:
Scratch the above idea... create a new type called bigint
Comment #12
Chris Johnson CreditAttribution: Chris Johnson commentedI advocate changing the priority of this ticket to critical and that once a reasonable fix is found, it be pushed into the next release of Drupal 6.
This is a multitude of problems just waiting to happen as the number of "things" get beyond signed 32 bit integers -- possibly including security holes.
Comment #13
Gábor HojtsyDuplicate of #499254: BIGINT handling which is more recent, but have a patch under discussion.
Comment #14
markus_petrux CreditAttribution: markus_petrux commentedGàbor: The other issue seems to be more focussed on partial BIGINT support, so this is not a dup. This one is mostly focussed on unsigned int support.
Comment #15
markus_petrux CreditAttribution: markus_petrux commentedI posted a patch to the other issue to avail this opportunity to also add support for unsigned ints. It looks like just one issue is enough.
Comment #16
alexanderpas CreditAttribution: alexanderpas commentednot a dup.
Comment #17
Anjuanoo CreditAttribution: Anjuanoo commentedI am trying to add a user and insert the user details to the drupal database.
Can anyone help me with the php code for the same.?
Comment #18
xurizaemonNo input on this in a long time, marking dupe of #2205277: Twitpocalypse issues redux.