Advertisement:

Author Topic: Bug Report: price in database  (Read 43608 times)

abc500x500

  • Jr. Member
  • **
  • Posts: 96
Bug Report: price in database
« on: April 16, 2016, 06:08:17 pm »
Hi
today i installed 3.6.1.
When i try to submit an ads it can not show larg digit for price!!!
I saw database and see i put for exam 999$ but it put to database 999000000 i_price fileld in t_item!

frosticek

  • Hero Member
  • *****
  • Posts: 3948
Re: Bug Report: price in database
« Reply #1 on: April 16, 2016, 10:04:29 pm »
@abc500x500
That is correct, as field in database is storing integers, not decimals, price you enter is multiplied by 1 000 000 and saved into database.
Then in price function of osclass price is divided by 1 000 000 and correct price is shown ;)

abc500x500

  • Jr. Member
  • **
  • Posts: 96
Re: Bug Report: price in database
« Reply #2 on: April 25, 2016, 12:40:22 pm »
@abc500x500
That is correct, as field in database is storing integers, not decimals, price you enter is multiplied by 1 000 000 and saved into database.
Then in price function of osclass price is divided by 1 000 000 and correct price is shown ;)
yes. I had found multiplied by 1 000 000  and divided by 1 000 000 in some files and i changed them and change db field to unsigned so problem solved.
Now user can put big amount price before that they only submit 6 digit price!!!
« Last Edit: April 25, 2016, 12:43:33 pm by abc500x500 »

abc500x500

  • Jr. Member
  • **
  • Posts: 96
Re: Bug Report: price in database
« Reply #3 on: April 25, 2016, 12:42:37 pm »
I know in India they change prices by /1000000 and *1000000 in softwares but for international it should not change and must original digit put to database

dev101

  • Osclass Hero
  • Hero Member
  • *
  • Posts: 2155
  • osclass.work
Re: Bug Report: price in database
« Reply #4 on: April 26, 2016, 02:44:53 pm »
This is not a bug, but a design feature. Although not a shop, it was designed for compatibility in mind, since processing prices requires 6-digit precision and this is one way to do it (on purpose). If you remove decimals behind floating point, you lose information. By multiplying values with 1M you keep them untouched in integers with goal precision, plus gain compatibility with different separators, as there is no need to store them.

abc500x500

  • Jr. Member
  • **
  • Posts: 96
Re: Bug Report: price in database
« Reply #5 on: April 30, 2016, 06:53:13 pm »
This is not a bug, but a design feature. Although not a shop, it was designed for compatibility in mind, since processing prices requires 6-digit precision and this is one way to do it (on purpose). If you remove decimals behind floating point, you lose information. By multiplying values with 1M you keep them untouched in integers with goal precision, plus gain compatibility with different separators, as there is no need to store them.
Thanks for illumination, but:

1)   /100 and *100 is better because 6 float digit is not usable! 1.000001$ or 1.000001# !!!

2) also unsigned field in data base is better because price always is +.

3) in many countries commodity and payments have big digit.
for exam:
in Armenia an Apple Macintosh desktop computer is 1,200,000 MNT
and in Iran that is 120,000,000RLS
a House in Iran is 200,000,000,000RLS
one USA dollar in Iran is 35,000RLS

if these become better then we can search and submit big prices not 6digit price!!!!