Allow more than 65535 products in cart/order by increasing quantity column sizes from smallint

That would be because the qty value is stored as 'unsigned short int'.

Although most stores wouldn't need to take orders of that quantity, for the sake of saving a couple of bytes it probably would just be easier to avoid this potential issue and use an 'unsigned int' to store quantities.

Re-rolled patch for Ubercart 6.x-2.2.

Although, I don't really think it needs to be patched - 16 bits is more than big enough for the quantity field. Anybody who buys 100,000 of anything is going to be using larger units than "each" For example, if I wanted to buy 100k sheets of paper, I would buy 200 reams, or 20 cases, or 1 pallet, etc.

Regardless, the patch should either be committed or this issue should be marked as "won't fix".

always the question, which field will run out earlier:

Qty or price fields. I hope it will be the qty, might otherwise get very expensive

Yes, that's another good point. I'm leaning heavily towards "will not fix" unless there's a compelling reason to alter the DB structure and deal with all the fallout that inevitably comes from a change like that.

I can think of one use case where allowing quantities of 100,000+ is useful - electronic components.

I have seen a site selling resisters for prices like - $0.012

Large quantities of resisters can be ordered as reels of 10,000 items, but this website still asks you to put in the number of resisters you want, so you might want to order 20 reels, but that needs to be entered as a quantity of 200,000 - even with this quantity it is still only a $2400 order so not unrealistic.

SHORT UNSIGNED INT is 2 bytes = max value 65K
UNSIGNED INT is 4 bytes = max value 4 billion

I agree that this is not going to be a common requirement, but changing from 2 to 4 bytes is only a minor change and basically removes any limitations on the quantity.

I myself prefer a order set for these kinds of products.
1 in the database = 100, 1000, 1 box or whatever. A simple hook_form_alter on the quantity field shows it to your customer.

your customer is not expected to purchase only 1 I presume?

Regards
Mark

I think that someone who would sell reels of resistors with Ubercart would list the reel as a separate product from the individual resistor. Even though I imagine you would order several different kinds of resistors at once, I still can't imagine there wouldn't be a minimum order quantity. I would probably sell sets of 10 or 100 as the smallest thing you can buy.

Of all the quantity fields in the Ubercart tables, only the package quantity isn't a short int. It ought to be changed for consistency, especially since it will never need values greater than the order's quantity anyway.

I also have an application that requires product quantities greater than 65,535. The solution proposed above is incomplete in that it only modifies the uc_order_products table. In order to be able to add a large quantity to your cart, you also need to modify the uc_cart_products table. I agree that this field size should be changed to INT in the Ubercart install.

Reopening as a feature request. Patch needs work, as noted in #9.

Submitting patch to update both uc_cart_products and uc_order_products qty fields from smallint to int.

Fixed an error (: instead of ;) and cleaned up the coding style, tested successfully.

Commit: http://drupalcode.org/project/ubercart.git/commitdiff/b0f6301

Ahh, I see what you mean, in uc_cart_update_7001(). Thanks for catching that, I'll make a note to check more closely next time. And thanks for your help through this, I'm looking forward to further work!

Here's a backport of the patch to D6.

I'm not sure how the upgrade path is working now, since D6 users won't get this DB change when they upgrade to D7, yet the D7 code will assume it has a larger qty column. I guess that just means that no-one who needs a larger quantities has upgraded yet. Anyway,
when this goes in we will need to change the D7 versions of uc_order_update_last_removed() and uc_cart_update_last_removed() to make sure this DB change gets applied for people who upgrade from D6 to D7.

@TR: Why won't D6 users get this if they upgrade? Any D6 -> D7 upgrade will involve running uc_cart_update_7001() and uc_order_update_7003(), which will increase the column size, or do nothing if the size has already been increased. We should never need to touch the hook_update_last_removed() functions.

Committed #15 and fixed the update function name in uc_order.install.