I've just attached an updated patch:
http://code.djangoproject.com/attachment/ticket/3182/3182.2.diff
Before I committed this I wanted to ask the list their thoughts of
Model.update() doing a save(force_update=True). Currently the patch
is just calling save(), which allows one to call update()
On Mar 15, 1:12 pm, "Gary Wilson Jr." wrote:
> What do you think?
Wouldn't this be a backwards-incompatible change at this point? It
would clash with any model fields named "update".
Dan
--~--~-~--~~~---~--~~
You received this message because you are subscribed t
On Sun, Mar 15, 2009 at 2:44 PM, Dan Watson wrote:
>
> On Mar 15, 1:12 pm, "Gary Wilson Jr." wrote:
> > What do you think?
>
> Wouldn't this be a backwards-incompatible change at this point? It
> would clash with any model fields named "update".
>
> Dan
> >
>
Take a look at the backwards compati
On Sun, Mar 15, 2009 at 2:44 PM, Dan Watson wrote:
> Wouldn't this be a backwards-incompatible change at this point? It
> would clash with any model fields named "update".
Technically, yes. However, if we interpret the backwards-compatibility
requirement this strictly it basically prevents us ad
On Mar 15, 4:40 pm, Jacob Kaplan-Moss
wrote:
> We take a slightly more reasonable approach to backwards compatibly as
> detailed
> athttp://docs.djangoproject.com/en/dev/misc/api-stability/#what-stable-
> Read that carefully: nothing there prevents us from adding a method
> named update.
Go
On Mar 15, 2009, at 05:02, Jeremy Dunck wrote:
> class CIDR_LIST(list):
>def __init__(self, cidrs):
>from IPy import IP
>self.cidrs = []
>try:
>for cidr in cidrs:
>self.cidrs.append(IP(cidr))
>except ImportError:
>pass
>
Yeah, dumb bug. :)
On Mar 15, 2009, at 4:12 PM, Ludvig Ericson
wrote:
>
> On Mar 15, 2009, at 05:02, Jeremy Dunck wrote:
>
>> class CIDR_LIST(list):
>> def __init__(self, cidrs):
>> from IPy import IP
>> self.cidrs = []
>> try:
>> for cidr in cidrs:
>>
On Sun, 2009-03-15 at 12:12 -0500, Gary Wilson Jr. wrote:
[...]
> Another option would be to allow Model.update() to take the
> force_update and force_insert parameters that save() does and just
> pass these through to the save() call.
Aside from the fact that I dislike the ideal as a whole (see
On Sun, Mar 15, 2009 at 4:40 PM, Malcolm Tredinnick
wrote:
> On Sun, 2009-03-15 at 12:12 -0500, Gary Wilson Jr. wrote:
>> Another option would be to allow Model.update() to take the
>> force_update and force_insert parameters that save() does and just
>> pass these through to the save() call.
>
>
On Sun, 2009-03-15 at 23:11 -0500, Gary Wilson Jr. wrote:
> On Sun, Mar 15, 2009 at 4:40 PM, Malcolm Tredinnick
> wrote:
> > On Sun, 2009-03-15 at 12:12 -0500, Gary Wilson Jr. wrote:
> >> Another option would be to allow Model.update() to take the
> >> force_update and force_insert parameters tha
> I'm very unconvinced that the idea in the ticket is worth it. It's a
> two-liner if somebody wants to do this in their code, so whilst we *can*
> add this method, adding yet another thing to Model namespace that also
> adds to the documentation and things that need to be tested, etc,
> doesn't s
The re-factored code moves the definition of default widgets for each
model field into an update-able dict and uses `if dbfield.__class__ in
self.formfield_overrides` to look up the correct widget for `dbfield`
instead of using `isinstance()`.
The problem arises when using a custom model field th
On Mon, Mar 16, 2009 at 1:32 AM, Tai Lee wrote:
>
> The re-factored code moves the definition of default widgets for each
> model field into an update-able dict and uses `if dbfield.__class__ in
> self.formfield_overrides` to look up the correct widget for `dbfield`
> instead of using `isinstance
13 matches
Mail list logo
