Code

Opened 3 years ago

Last modified 3 years ago

#15678 new New feature

Different behaviour for DecimalField on MySQL and SQLite

Reported by: max@… Owned by: nobody
Component: Database layer (models, ORM) Version: 1.3
Severity: Normal Keywords: sqlite, mysql, decimalfield
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Consider the following model:

class Product(models.Model):
    title   = models.CharField('Title', max_length=250)
    price   = models.DecimalField('Price', max_digits=9, decimal_places=2, default=0)

If you create or modify an object in the admin using MySQL and set the price to "0" with will automatically become "0.00".

But if you do the same using SQLite3, it will allow it to stay "0".

I know that the two backends doesn't provide the same features support and both store DecimalFiels differently, but couldn't the ORM deal with it transparently ?

Attachments (0)

Change History (7)

comment:1 Changed 3 years ago by lukeplant

  • Type set to New feature

comment:2 Changed 3 years ago by lukeplant

  • Severity set to Normal

comment:3 Changed 3 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

I'm on the fence here - different dbs are different. Is there a compelling argument that we should bother fixing this?

comment:4 Changed 3 years ago by anonymous

Well I think Django should abstract databases inconsistencies when it's possible.. since we are perfectionists with deadlines :>

Furthermore in this case we are talking about the representation of a specific data type. So I think it would make sense to handle it with input validation, I don't think that it counts as emulating a missing database feature.

comment:4 Changed 3 years ago by anonymous

Well I think Django should abstract databases inconsistencies when it's possible.. since we are perfectionists with deadlines :>

Furthermore in this case we are talking about the representation of a specific data type. So I think it would make sense to handle it with input validation, I don't think that it counts as emulating a missing database feature.

comment:5 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:6 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.