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
On Mon, Mar 9, 2009 at 11:11 AM, Casper Star wrote:
> On Mar 9, 11:48 am, Malcolm Tredinnick
> wrote:
> > This is getting ridiculous.
>
> This seems to move towards some kind of religious war (this is
> ridiculous by its very nature) and I surely could live we either
> decision . But I would expe
On Mar 9, 11:48 am, Malcolm Tredinnick
wrote:
> This is getting ridiculous.
This seems to move towards some kind of religious war (this is
ridiculous by its very nature) and I surely could live we either
decision . But I would expect django as a python webframework to mimic
the python implemen
On Mon, Mar 9, 2009 at 5:48 AM, Malcolm Tredinnick wrote:
>
> This is getting ridiculous.
>
> On Mon, 2009-03-09 at 03:20 -0700, Semmel wrote:
> > On Mar 6, 7:24 am, Russell Keith-Magee wrote:
> > > Both options are supported _in many cases_. Not _all_ cases. The
> > > Sunday=1 case is supported
On Mon, Mar 9, 2009 at 5:25 AM, David Reynolds
wrote:
>
> Hi,
>
> I need to use some sort of model validation in a project I am working
> on and I wondered what that status of
> http://code.djangoproject.com/ticket/6845 is.
>
> Is the github code useable for production? Is there anything I can do
This is getting ridiculous.
On Mon, 2009-03-09 at 03:20 -0700, Semmel wrote:
> On Mar 6, 7:24 am, Russell Keith-Magee wrote:
> > Both options are supported _in many cases_. Not _all_ cases. The
> > Sunday=1 case is supported by all the backends.
>
> Imho that's no real argument. Yeah, i can und
Hi,
I need to use some sort of model validation in a project I am working
on and I wondered what that status of
http://code.djangoproject.com/ticket/6845 is.
Is the github code useable for production? Is there anything I can do
to help with it? Is there a recommended workaround for model
validat
On Mar 6, 7:24 am, Russell Keith-Magee wrote:
> Both options are supported _in many cases_. Not _all_ cases. The
> Sunday=1 case is supported by all the backends.
Imho that's no real argument. Yeah, i can understand why this was
choosen in the first way (because it's somehow easier to implement)
12 matches
Mail list logo
