Deprecate change pk + save behavior for 1.4

I am suggesting the following PK change behavior will be deprecated in 1.4. The problem is this: class SomeModel: name = models.CharField(max_length=20, primary_key=True) s = SomeModel(name='foo') s.save() s.name='bar' s.save() At this point you end up with both 'foo' and 'bar' objects in

Re: Allowing models to influence QuerySet.update

On Nov 30, 12:31 am, Carl Meyer wrote: > > Now, this is not that inefficient - but it would be a good > > optimization to NOT fetch the instances if there are no listeners for > > pre/post delete signals and there are no cascades (or all cascades are > > DO_NOTHING). Even if

Re: Allowing models to influence QuerySet.update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2011 02:58 PM, Kääriäinen Anssi wrote: > """ > H, that is not ideal behavior. You mean QuerySet.delete() calls > the signal for each deleted object, rather than doing a delete at the > database level? > """ These two things aren't

RE: Allowing models to influence QuerySet.update

""" H, that is not ideal behavior. You mean QuerySet.delete() calls the signal for each deleted object, rather than doing a delete at the database level? """ This might not be exactly accurate, but I think it goes something like this: - Fetch all the to-be deleted objects (one query) -

Re: Allowing models to influence QuerySet.update

On Tue, Nov 29, 2011 at 3:27 PM, Kääriäinen Anssi wrote: > Is this correct for delete? A quick test (A1 is a model which I have hanging > around - details about it aren't important): > > from django.db.models.signals import post_delete > > def foo(*args, **kwargs): >    

RE: Allowing models to influence QuerySet.update

""" I also noticed in db optimization docs that we have explicitly documented update() and delete() as bypassing signals, and I think we should honour that. https://docs.djangoproject.com/en/dev/topics/db/optimization/#use-queryset-update-and-delete """ Is this correct for delete? A quick test

Re: Allowing models to influence QuerySet.update

On Nov 29, 1:17 pm, Luke Plant wrote: > On 29/11/11 17:10, Paul Winkler wrote: > > > Hmm. I've been thinking of signals as key plug points for third-party > > apps, as well as a way to avoid needing database-specific stored > > procedures and triggers. Maybe I need to

Re: Allowing models to influence QuerySet.update

On 29/11/11 17:10, Paul Winkler wrote: > Hmm. I've been thinking of signals as key plug points for third-party > apps, as well as a way to avoid needing database-specific stored > procedures and triggers. Maybe I need to rethink that. Signals could be used for your use case, as an alternative to

Re: Django 1.4 roadmap

2011/11/29 Luke Plant > 2) Broken tests: > > http://ci.djangoproject.com/builds > > It looks like tests are failing on Oracle and spatialite. I guess any > failing tests need to be added to the release blockers. > I don't think there are any reproducible failures under

Re: Allowing models to influence QuerySet.update

On Nov 29, 7:25 am, Luke Plant wrote: > The docs for QuerySet.update() already say that no post_save/pre_save > signals are emitted. Mea culpa, somehow I missed that. Thanks for pointing it out, and updating the ticket. Hmm. I've been thinking of signals as key plug

Re: Django 1.4 roadmap

On Tue, Nov 29, 2011 at 5:10 AM, Luke Plant wrote: > 2) Broken tests: > > http://ci.djangoproject.com/builds > > It looks like tests are failing on Oracle and spatialite. I guess any > failing tests need to be added to the release blockers. I'll make a note to go through

Re: Django 1.4 roadmap

On Tue, Nov 29, 2011 at 13:40, Tomek Paczkowski wrote: > What happend to "SVN is least common denominator"? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit >

Re: Django 1.4 roadmap

> > > Since we never had a list of features that we were committing to adding > for 1.4, I don't see any reason why we can't release an alpha as soon as > > the release blockers are dealt with. Agreed. There will > always be extra

Re: Django 1.4 roadmap

What happend to "SVN is least common denominator"? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/5DgmsJ17_8oJ. To post to this group, send

Re: Django 1.4 roadmap

On 29.11.2011, at 13:31, Luke Plant wrote: > On 29/11/11 12:23, Jannis Leidel wrote: > >> Definitely, we've never intended to ship Python 3 support in 1.4 and I >> would even say that targeting 1.5 is a very eager goal giving the amount >> of code and non-code work is required to be done for a

Re: Django 1.4 roadmap

On 29/11/11 12:23, Jannis Leidel wrote: > Definitely, we've never intended to ship Python 3 support in 1.4 and I > would even say that targeting 1.5 is a very eager goal giving the amount > of code and non-code work is required to be done for a full port (e.g. > docs, dependencies, etc). I think

Re: Django 1.4 roadmap

On Tue, Nov 29, 2011 at 8:10 PM, Luke Plant wrote: > On 28/11/11 20:33, Adrian Holovaty wrote: > >> And that someone will be me. See my post here: >> http://www.holovaty.com/writing/back-to-django/ > > Great stuff! > >> I plan on starting this next week. Is there a list

Re: Allowing models to influence QuerySet.update

On 28/11/11 18:28, Paul Winkler wrote: > There was an old thread about this at > https://groups.google.com/group/django-developers/browse_frm/thread/6e41ee7b08d50710/9cf6375d97bed499?lnk=gst=update+signal#9cf6375d97bed499 > which fizzled out last summer with no conclusion. > (I'd reply to that

Re: Django 1.4 roadmap

On 29.11.2011, at 13:10, Luke Plant wrote: > On 28/11/11 20:33, Adrian Holovaty wrote: > >> I plan on starting this next week. Is there a list somewhere of what >> needs to get done? If not, I can make it, but obviously it'd be great >> if that already existed. > > 3) We don't have a fully

Re: Django 1.4 roadmap

On 28/11/11 20:33, Adrian Holovaty wrote: > And that someone will be me. See my post here: > http://www.holovaty.com/writing/back-to-django/ Great stuff! > I plan on starting this next week. Is there a list somewhere of what > needs to get done? If not, I can make it, but obviously it'd be

Re: Django 1.4 roadmap

- *Release version 1.4.* - *Move to Git/GitHub.* I Now, that's a start! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit

Re: New feature: Defining fieldsets in form class (Ticket #17301)

Hi Carl, To be honest, I think that Django will never achieve complete separation in terms of MVC model staying this convenient tool. There are many places where Django has a simple way of doing things, even when it's not full MVC-compilant. Current Form.as_(table|ul|p) methods are examples. I