Products weight decimal

[Pierre_P]

Any reason for the products table, products_weight column having only 2 decimals?
For precision i changed to DECIMAL(6,3) expanding decimal weight to 999.999

Reasoning is we have items weighing 1 gram - and similar with other small items we need to record this as 0.01 or 10 grams increasing weight 10 fold.
When getting to our shipping cost calculations the parcel weight is basically incorrect.
Also our shipping modules is coded for logic using different box sized parcels limited by weight factors increasing probability for incorrect shipping cost to the end users.

For other shop owners i assume the current weight 5,2 (999.99) is sufficient on a basic level.
Perhaps dev's to have a look at this decimal increase for future Phoenix versions.

[burt]

That's fine to do I'd have thought this would introduce no problems.
Good on you for doing that change.

What if someone else wants weights over the 6,3 limit ?

--

Phoenix is not and can never be a "one size fits all" solution that suits all shopowners.
The beauty is, because the code base is so very simple.. you can do as you have done.
And so can the next person who might want micrograms, or the next who might want ounces.
Or the next who needs "this" (whatever this might be), when Phoenix comes supplied with "that".

[14Steve14]

For precision i changed to DECIMAL(6,3) expanding decimal weight to 999.999.

We did the same many years ago as all our product weights are entered as grams. We also changed in the shipping modules from Lbs to Kgs and have had no problems with our shipping calculations. We never send out really heavy orders to the weight limit is not really a problem.

[ecartz]

We did the same many years ago as all our product weights are entered as grams.

No. All your masses are entered as kilograms with gram precision. If they were entered as (whole) grams, you could set it to DECIMAL(3, 0) and get the same precision. You wouldn't need 6, 3. I.e. you are entering 10 grams as 0.010 kg, not 10 g.

It's a database change, so you can set the precision to whatever you want and it will persist through updates. It probably needs to stay DECIMAL and not INT for consistency, but which DECIMAL precision doesn't really matter.

DECIMAL(5, 2) uses three bytes of storage. (6,3) uses four. Note that (7, 3) also uses four(as does (8,4), but that won't help with gram precision). DECIMAL(4,2) would use two bytes of storage, as would (2, 1). We could go to DECIMAL(6, 2) without changing the storage size.

Anyway, if you're fine with four bytes of storage (e.g. (7, 3)), that's OK. Go ahead. But that's a tradeoff that you are choosing to make. Others may prefer different amounts, e.g. DECIMAL(9, 0) in four bytes would store grams or ounces up to 999,999,999. Or prefer three bytes of storage.