On Tue, 2009-03-10 at 14:19 +1100, Malcolm Tredinnick wrote:
> On Mon, 2009-03-09 at 15:46 -0600, Ian Kelly wrote:
[...]
> > There may also be an argument for removing the seemingly redundant
> > get_db_prep_save call from save_base.
>
> Which would break large amounts of code, so let's not do t
On Mon, 2009-03-09 at 15:46 -0600, Ian Kelly wrote:
> After r10003, Model.save() raises an error in Oracle if the model
> includes a TimeField. The reason appears to be that save_base calls
> TimeField.get_db_prep_save prior to passing the value on to the
> queryset, which calls TimeField.to_pyth
Are you using timezone aware datetime objects? If so, see
http://code.djangoproject.com/ticket/10443
Simon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
On Mon, Mar 9, 2009 at 3:46 PM, Ian Kelly wrote:
> There may also be an argument for removing the seemingly redundant
> get_db_prep_save call from save_base. Any thoughts on that?
I should add that the main thing that concerns me about this fix is
that it would make save_base internally inconsi
After r10003, Model.save() raises an error in Oracle if the model
includes a TimeField. The reason appears to be that save_base calls
TimeField.get_db_prep_save prior to passing the value on to the
queryset, which calls TimeField.to_python -- returning a time instance
-- and then passes the resul
