Code

Opened 5 years ago

Closed 4 years ago

Last modified 3 years ago

#11333 closed Uncategorized (wontfix)

ORA-01830 date format picture ends before converting entire input

Reported by: jtiai Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords: oracle date formats
Cc: mboersma Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I've legacy database that uses 'DATE' field and I'm using DateTimeField. Getting error: ORA-01830 date format picture ends before converting entire input if I'm using auto_now_add fields for fields that contain no fractions.

If I do following:

from models import MyModel

e = MyModel.objects.all()[0]
e.save()

Symptoms are exactly as in #9275, but even I'm using SVN it doesn't work.

Attachments (0)

Change History (8)

comment:1 Changed 5 years ago by anonymous

  • Component changed from Uncategorized to Database layer (models, ORM)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 5 years ago by ikelly

  • Cc mboersma added
  • milestone set to 1.2
  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 4 years ago by russellm

  • milestone 1.2 deleted

Not critical for 1.2

comment:4 Changed 4 years ago by russellm

  • milestone set to 1.3

comment:5 Changed 4 years ago by ikelly

  • Resolution set to wontfix
  • Status changed from new to closed

In order to fix this, we would need to somehow distinguish whether a DateTimeField is implemented in the database as a DATE or TIMESTAMP column. I can see two ways of doing this:

  1. By doing automatic introspection on every DateTimeField at start-up in order to determine the actual column types. This would be quite a bit heavier than the introspection we currently do, and it doesn't seem very practical to me.
  1. By adding a precision keyword argument to DateTimeField and TimeField that denotes the fractional second precision to be used. This might be a worthwhile feature to add, but it's outside the scope of this ticket.

Also, there are a full complement of workarounds here. Either use a DateField with a DATE column, or a DateTimeField with a TIMESTAMP column, or if you really need to mix and match, turn off auto_now and use a pre_save signal to manually set the field with the correct precision.

So my conclusion is that the proper response to this for now is "don't do that", and I'm closing this as wontfix.

comment:6 Changed 3 years ago by anurag.chourasia@…

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized
  • UI/UX unset

If the model field is a DateTimeField and the Database field is of DATE Type then you could try this to overcome this error

Look for the statement where you are updating the Date field. Over there, replace the microseonds to Zero and Oracle will start treating it gracefully.

For example, if you model field is called date_field

and if you are updating it as

date_field=datetime.datetime.now()

then change it to

date_field=datetime.datetime.now().replace(microsecond=0)

And that will solve the issue

Regards
Guddu

comment:7 Changed 3 years ago by jtiai

Thanks for the info. Though it doesn't solve problem when you update non-date fields (Django updates still whole record) problem still exists.

I agree with ikelly, it's better to do it right than trying to hack around someway. Though it could be useful to mention that workaround in official docs as well.

comment:8 Changed 3 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


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

 
Note: See TracTickets for help on using tickets.