View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005774 | OXID eShop (all versions) | 1.03. Basket, checkout process | public | 2014-05-23 14:54 | 2023-11-27 16:44 |
| Reporter | FibreFoX | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | reopened | ||
| Product Version | 4.8.5 / 5.1.5 | ||||
| Summary | 0005774: oxuserbasketitems storing amount by char (should be double) | ||||
| Description | The table oxuserbasketitems is used for persisting the basket until the customer comes back or reloggs into his account, but if you enable non-integer amounts, that values aren't stored right | ||||
| Tags | Database, Product domain and basket rewrite | ||||
| Theme | Azure | ||||
| Browser | All | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
|
|
Reminder sent to: FibreFoX Hi, Thank you a lot for submitting this issue, but for us is no clear which behaviors is incorrect. If it's still the issue - please give us more details about the case? Best regards, Jurate |
|
|
The stored basket for users doesnt takes account for non-integer amounts like orderarticles does. Enabled the setting "Allow fraction Quantities (e.g. 1.5) " (blAllowUnevenAmounts). SQL queries: CREATE TABLE `oxuserbasketitems` ( ... `OXAMOUNT` char(32) NOT NULL default '' COMMENT 'Amount', ... CREATE TABLE `oxorderarticles` ( ... `OXAMOUNT` double NOT NULL default '0' COMMENT 'Amount', ... the table oxuserbasketitems should be double instead of char. |
|
|
Generally DOUBLE type is not a recommended type for storing financial data. See: http://dev.mysql.com/doc/refman/5.1/en/problems-with-float.html The candidate type for storing basket data might be DECIMAL here. However when implementing that please do not forget its own repercussions (e.g. calculated result value 1.559 might be rounded to 1.55 instead of 1.56). |
|
|
No note why this is closed? -> reopen the amount isn't holding "financial data". if oxuserbasketitems is switched to decimal, the oxorderarticles should be changed too (maybe other databases/models too). |
|
|
Reminder sent to: FibreFoX Hi, As mention in previous note Double type is not a recommended type for this case. Char type currently is a risk free choice unless it affects the functionality in a negative way. Do you know any use cases where given type could cause any functionality problems? Best regards |
|
|
Hi, so if CHAR(32) is the right choice, it should be in oxorderarticles as well :) in that case oxuserbasketitems is the correct one. At least ONE database-table is wrong. |
