Lack of interest Decimal support for counter column in xf_stats_daily

[DragonByte Tech]

At the moment, the counter is limited to integers, which is sub-optimal for things like currency / income which requires two decimals.


Fillip

 

[Chris D]

I'm not sure if we'd make that change or not, but FYI there's a workaround which I think should be sufficient, if you're not using it already.

I'd recommend storing the value in pence/cents and then formatting it using the adjustStatValue method. There's an example in XF\Stats\Attachment where we store the attachment disk usage as bytes but then convert it to MB for display.

 

[DragonByte Tech]

I'm not sure if we'd make that change or not, but FYI there's a workaround which I think should be sufficient, if you're not using it already.

I'd recommend storing the value in pence/cents and then formatting it using the adjustStatValue method. There's an example in XF\Stats\Attachment where we store the attachment disk usage as bytes but then convert it to MB for display.

Interesting, I didn't know that. I implemented it internally just now and it appears to work fine. Thanks

I'd say this can be closed, given the grief we had with the PayPal code I don't see a single reason to even entertain the possibility of introducing similar issues with the statistics interface. Not to mention, since the DECIMAL MySQL type uses zerofill for the precision, you would also need to apply zero-decimal number formatting to literally every single statistic where decimals are irrelevant.

The downsides are just far too numerous, when this workaround exists.

If we ever sell enough in a single day that BIGINT(20) isn't enough because of the two decimal places, then I'll be too busy picking out the colour of my yacht to come back here to complain


Fillip