Closed (fixed)
Project:
Money field
Version:
5.x-1.3
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
6 Dec 2007 at 20:13 UTC
Updated:
5 Mar 2008 at 21:24 UTC
I've implemented the CCK Money module in my site and works really good. The problem comes when I have to submit a large numbers, let's say U$S 50,000,000. I know that not everyone needs a huge field in their databases, but it would be good to make this optional.
Comments
Comment #1
wim leersFrom
money_field_settings()(the implementation of the hook_field_settings() CCK hook):As you can see, I've set the amount to be integers of length 13. The last two of those are used for decimals, which leaves you with 11 symbols left, enough for almost 100 billion. Seems enough to me.
However, when I try the amount you suggested (fifty million), it is processed to somehow be -1. I'll have to figure out why that happens.
A patch is welcome, of course :)
Comment #2
soflete commentedSorry, I thought there was a lower limit. I also believe that a hundred billion is enough. I'll try to find the problem myself, and if I succed I'll let you know. Thanks.
Comment #3
wim leersExcellent! Looking forward to get to know about the cause of this. I tested this:
And that worked just fine. So it's not that PHP can't handle numbers that big (which would be silly too).
Comment #4
soflete commentedIt definetly has something to do with using an int for storing the value. The maximum value you can submit is 2147483648, wich is the maximum value for integer as I read in the pages of mysql: http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html. I have never made a CCK field module, but I'll check how this can be changes to bigint or similar. What do you think? Greetings.
Comment #5
wim leersThat's it!
2147483648
versus
5000000000 (50 million * 100 cents)
That's almost twice as big as the allowed size. Sigh. I set it to bigint, keeping the same length (13), and voila, it worked. At least, I could get it working in MySQL. Now it won't work in PHP, or Drupal, or CCK. SIGH! I hope you can continue your search now.
Comment #6
soflete commentedThat's true, I changed it to bigint in the CCK definition. When I check the field in the database it's actually a bigint, anyway there is something in the middle that still keeps converting the value into an int. Could it be a CCK module issue? I'll keep looking.
Comment #7
soflete commentedLook at what I found: http://drupal.org/node/76432 Looks like there's a problem with CCK number conversion. So perhaps the solution is out of the scope of this module. What do you think?
Comment #8
wim leersYou're probably right. I'll have to look at it more in-depth though, to confirm that that's the cause. If you'd like to help narrow down the cause, start looking in the code that handles the DB interaction.
Comment #9
wim leersI've now configured the database definition to use bigint. If you encounter any problems, please open a new issue.
Comment #10
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.