Re: About the django-core mailing list

[Dennis Kaarsemaker]

On do, 2010-09-09 at 12:30 -0500, Jacob Kaplan-Moss wrote:

> The goal is to only be private when we absolutely *must*, and if we're
> not sufficiently transparent *please* say something. 

Thanks Jacob, for explaining this.

This makes a good amount of sense, and Django is not unique here. I am
involved with other high-profile open source projects where similar
'core' lists exist for the very same reasons, except for the
coordination bits, which you already addressed as possibly being a bad
topic for a private list. It works very well for these projects and I am
convinced it works well for any project, if used responsibly.

-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.3 and Python 2.4

[Dennis Kaarsemaker]

On Wed, Aug 11, 2010 at 2:20 AM, Russell Keith-Magee
 wrote:

> Like it or not, RHEL is still a major player in the enterprise market
> at the moment. I can't speak for the US, but in Australia at least --
> when all those companies got on the Linux bandwagon in the mid 2000's,
> they all adopted RHEL, and being large enterprises, they aren't moving
> away from that platform in a hurry. I don't particularly want to rush
> this segment of Django's market share into the arms of another
> framework.
>
> I'd rather defer dropping support for Python 2.4 until Django 1.4;
> that way, we can use the 1.3 release notes to draw attention to the
> impending deprecation.
>
> On top of that, RHEL5 moves into support mode (production 2) at the
> end of Q1 2011, and into long-term support mode (production 3) in Q1
> 2012. A Django 1.4 release would roughly coincide with the start of
> support mode. Also, by that time, RHEL6 will hopefully be out,
> hopefully providing a more recent Python release as a baseline, which
> will provide a way forward for those with support contracts.
>
> Past that point, I think we will probably be able to get more
> aggressive about dropping Python versions, but let's cross that bridge
> when we get to it.

As one of those RHEL users in larger environments, I really appreciate
this policy and the fact that you have so far followed it and are
planning to continue doing so. Makes my life a lot easier.

FWIW, RHEL 6 will use python 2.6.
-- 
Dennis K.

Time is an illusion, lunchtime doubly so.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Querysets with "only()" and "defer()" slower than without?

[Dennis Kaarsemaker]

On do, 2010-08-05 at 16:09 -0500, Jacob Kaplan-Moss wrote:

> - What database engine are you using?
> - Where's the database being stored (same server? other server?
> in-memory?)
> - How much data is in the database?
> - How big is that "info" field on an average model? 

- Were OS/database level caches equally hot or cold?
-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

On wo, 2010-07-28 at 14:20 -0500, Jacob Kaplan-Moss wrote:
> On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker
> <den...@kaarsemaker.net> wrote:
> > As implemented in my github branch it is called once (well, twice, pre
> > and post) per update() statement, not once per object.
> 
> Okay, I missed that -- sorry.
> 
> Doesn't really change how I feel about the feature, though: I don't
> see the point in needlessly complicating what's supposed to be a very
> thin wrapper around an UPDATE call. I haven't really heard a good
> argument *for* the feature -- "I want it" isn't a great argument, and
> there's already been a couple of suggestions to otherwise achieve the
> feature.

But not yet a suggestion that integrates with third party applications
without modifying them, which is one of the reasons I implemented this.
(The other reasons basically come down to "i want it" as complete
auditing, including update() is a requirement I have for a few projects)

On the other hand, I see no reasons not to include the feature as it
doesn't get in the way, is useful and comes with documentation and
tests. It doesn't make update() more complicated to use and four lines
of easy to understand code (2 for defining the signals and 2 for
sending) are not difficult to understand either for people maintaining
the code.

-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

On wo, 2010-07-28 at 13:43 -0500, Jacob Kaplan-Moss wrote:
> On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker
> <den...@kaarsemaker.net> wrote:
> > This would add boilerplate to each class and makes it nontrivial to do
> > update() tracking for third party applications. I don't see why pre/post
> > update signals are worse than pre/post save and delete.
> 
> Because the save/delete signals get called once when a single object
> is saved/deleted. An update signal would have to be called once for
> each object in the queryset. That is, if `SomeModel.objects.all()`
> returns a thousand results, `SomeModel.objects.update(foo='bar')`
> would have to call the update signals one thousand times.
> 
> This is why I refer to update() as an optimization. If you must have
> Python-side behavior during a bulk update, iterate over the queryset
> and call save. If you want performance, do it in the database. There
> isn't a middle ground.

As implemented in my github branch it is called once (well, twice, pre
and post) per update() statement, not once per object.

> > Signals itself
> > are pretty lightweight (two function calls per update()) and are
> > separate from the rest of the proposal.
> 
> Doesn't matter how lightweight they are: cheap != free. We've
> benchmarked this before, and you're right that it's small. But
> anything that could potentially be called O(N) times needs to be very
> carefully considered here.

If it were called N times, i'd agree. But it is not.

> > For making auto_now and similar functions work with update(). Currently
> > auto_now fails in the face of update(), which is not documented.
> 
> Well, that's a documentation bug, then.
> 
> FTR, auto_now and friends have been close to being deprecated for
> quite a while -- they're impossible to do easily and cheaply, and
> (again) are better done in-database. I'll probably start taking the
> steps to marking them deprecated in 1.3.

Ah... that's unexpected. I presume that the deprecation will be followed
by documentation on how to set this up in databases that support them?

-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

On wo, 2010-07-28 at 12:02 -0500, Jacob Kaplan-Moss wrote:
> Hi Dennis --
> 
> I'm not totally thrilled with this proposal, though perhaps there's
> some points I just don't get. As it is, though, I'm -0 on the idea.
> update() is supposed to be an optimization that's "close to the metal"
> of the database; adding potentially-hidden slow code to the mix rubs
> me the wrong way.
> 
> In general, signals are a very dangerous thing: they make side-effects
> non-obvious, and make it hard to discover what's going to be called
> when. They also add a not-insignificant overhead. I'm of the opinion
> that they should be avoided except where critically important, and I
> don't see this to be one of those cases.
> 
> On Wed, Jun 16, 2010 at 7:38 AM, Dennis Kaarsemaker
> <den...@kaarsemaker.net> wrote:
> > However, I'd like to have a bit more control over what update() does,
> > e.g. for auditing purposes. I know that I can simply write a few lines
> > of code near every update() call to do what I want, but that violates
> > DRY.
> 
> I think you may have missed a few possibilities in your search for a
> DRY solution to the problem. If I was trying to add some audibility
> around QuerySet.update() I would:
> 
> 1. Define a QuerySet subclass that extended update() to provide
> whatever hooks I needed (this could be a signal, perhaps, or just the
> code).
> 
> 2. Make a Manager subclass that returned by QuerySet object from
> get_query_set().
> 
> 3. Use said Manager (or a subclass) on each model that I want the behavior on.

This would add boilerplate to each class and makes it nontrivial to do
update() tracking for third party applications. I don't see why pre/post
update signals are worse than pre/post save and delete. Signals itself
are pretty lightweight (two function calls per update()) and are
separate from the rest of the proposal.

> This gives me control over *where* my added behavior happens, and it's
> completely clear to anyone reading the code that I've got a custom
> Manager; they can follow the trail to the update behavior.
> 
> > * An update() method for Model.
> >  This method is a classmethod because it does not deal with instances
> >  but querysets. It calls pre_update on all of its fields.
> >
> > * A pre_update method for Field that does nothing
> >  Simply exists so that it doesn't have to be checked for
> >
> > * A pre_update method for DateField for auto_now magic
> >  This method adds an update for the relevant field to the dict of
> >  updates. This means that auto_now really is auto_now, also when
> >  using update()
> 
> This is the part that I *really* don't understand -- why do you need
> all the extra mechanism? You've now added (num_fields *
> num_objects_in_queryset) function calls to each update() call...

For making auto_now and similar functions work with update(). Currently
auto_now fails in the face of update(), which is not documented. I chose
to make auto_now work but could live with the current status being
better documented and not having the above functionality. I could simply
implement it for my projects as a listener for the pre_update signal :)

> So yeah, I'm pretty against this proposal, *especially* as implemented.

Are you against just the signals too (so, only the first of the four
patches)? Your negative reactions seem to concern mostly the additions
to Model and Field.

> Now, all that said, there's a kernel here I'm interested in exploring.
> If you follow the steps I outline above, you could pretty easily make
> a reusable app that provided QuerySet signals, but that app would only
> work with apps that explicitly depended upon it. That is, if I wanted
> to receive update() signals from auth.User, I'd be SOL.

This is why I think a pre/post update signal is a good idea. It is the
same sort of signal as the _save and _delete signals which django has
had for a long time.

> This dovetails with an idea I had recently: I think it's probably
> about time we added a mechanism for apps to contribute methods or
> behavior to QuerySets. I haven't thought it out fully, but I think
> that the best way for you to proceed might be to consider the greater
> question of how we might go about allowing project-wide QuerySet
> extensions.

Oh, that's a neat idea. Quick brainstorm:

- Having a settings.DEFAULT_MANAGER / settings.DEFAULT_QUERYSET setting 
  so people can subclass QuerySet and use it as default
  Pro: Should be fairly easy to implement on the django side
  Con: Existing managers might need to be changed to subclass
   settings.DEFAULT_MANAGER instead of the current parent
- Have an api to add functionality to the manager/queryset
  Pro: No rewriting of existing code needed
  Con: Feels like monkeypatching

Re: Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

Is nobody interested?

I'm using this in production for auditing purposes and works just fine.
If only it were built in, then I wouldn't have to monkeypatch :)

I've rebased it to trunk again and it still works.

On wo, 2010-06-16 at 14:38 +0200, Dennis Kaarsemaker wrote:
> I know that queryset.update does not call .save() for each instance and
> I know why. I even agree with it :)
> 
> However, I'd like to have a bit more control over what update() does,
> e.g. for auditing purposes. I know that I can simply write a few lines
> of code near every update() call to do what I want, but that violates
> DRY.
> 
> I have created ticket #13021[1] and created a github branch[2] that
> provides the following:
> 
> * Two new signals: pre_update and post_update
>   The argument for these signals is the queryset and a dict of all 
>   changes that will be or have been applied to the objects in that set.
> 
> * An update() method for Model.
>   This method is a classmethod because it does not deal with instances 
>   but querysets. It calls pre_update on all of its fields.
> 
> * A pre_update method for Field that does nothing
>   Simply exists so that it doesn't have to be checked for
> 
> * A pre_update method for DateField for auto_now magic
>   This method adds an update for the relevant field to the dict of 
>   updates. This means that auto_now really is auto_now, also when 
>   using update()
> 
> * A patched QuerySet.update() to use the above features.
>   - It sends the pre_update and post_update signals
>   - It calls the models update method to update the kwargs dict
> 
> * Tests and documentation for these features
> 
> I've sent this proposal a few months ago and have kept the patch up to
> date since. It still applies (I've just rebased it to trunk) and the
> tests still pass.
> 
> Thanks in advance for considering and commenting,
> 
> [1] http://code.djangoproject.com/ticket/13021
> [2] http://github.com/seveas/django/tree/seveas/ticket13021

-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

I know that queryset.update does not call .save() for each instance and
I know why. I even agree with it :)

However, I'd like to have a bit more control over what update() does,
e.g. for auditing purposes. I know that I can simply write a few lines
of code near every update() call to do what I want, but that violates
DRY.

I have created ticket #13021[1] and created a github branch[2] that
provides the following:

* Two new signals: pre_update and post_update
  The argument for these signals is the queryset and a dict of all 
  changes that will be or have been applied to the objects in that set.

* An update() method for Model.
  This method is a classmethod because it does not deal with instances 
  but querysets. It calls pre_update on all of its fields.

* A pre_update method for Field that does nothing
  Simply exists so that it doesn't have to be checked for

* A pre_update method for DateField for auto_now magic
  This method adds an update for the relevant field to the dict of 
  updates. This means that auto_now really is auto_now, also when 
  using update()

* A patched QuerySet.update() to use the above features.
  - It sends the pre_update and post_update signals
  - It calls the models update method to update the kwargs dict

* Tests and documentation for these features

I've sent this proposal a few months ago and have kept the patch up to
date since. It still applies (I've just rebased it to trunk) and the
tests still pass.

Thanks in advance for considering and commenting,

[1] http://code.djangoproject.com/ticket/13021
[2] http://github.com/seveas/django/tree/seveas/ticket13021

-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django bugfix releases

[Dennis Kaarsemaker]

On di, 2010-05-25 at 17:22 -0700, Mikhail Korobov wrote:

> I think the releases of stable micro-releases should happen more often
> for 1.2. You guys are doing great job and it is not good to hide it
> from developers. 

This issue has been raised before and improvements were promised. I
believe that it will happen. 
-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Dennis Kaarsemaker]

On zo, 2010-04-25 at 23:15 +0800, Russell Keith-Magee wrote:

> However, the *huge* impediment that you have avoided mentioning is
> that moving to Launchpad would require moving Django to using Bazaar
> for version control. 

You don't *have* to use the bzr/code bits of launchpad to use the
bugtracking or translation features.

> Even if we were to adopt a DVCS, given the popularity of Git and Hg in
> the Django community, adopting Bazaar would be a strange choice for us
> to make at a project level.

Github has an issue tracker and merge request thing :) 
(Never used it though, I'm not suggesting it as an alternative to trac)

-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Process discussion: reboot

[Dennis Kaarsemaker]

On ma, 2010-04-19 at 15:47 +, Peter Landry wrote:
> 
> 
> On 4/19/10 11:41 AM, "Jacob Kaplan-Moss"  wrote:
> 
> > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry  wrote:
> >> One suggestion that jumped out at me (which I admittedly know very little
> >> history about with regards to Django or other projects) was the "trunk
> >> ready" branch(es) [1]. Perhaps an effort to outline what that process might
> >> entail in detail, to determine if it would address any concerns?
> > 
> > FTR, I think this is a fine idea, and I think most (all?) of the other
> > Django core developers do, too. It's just waiting on someone to Just
> > Do It.
> > 
> > Anyone -- preferably a group -- who wants to start such a branch could
> > go ahead and start one using the DVCS tool of their choice (Django has
> > semi-official clones on Github, Bitbucket, and Launchpad). Tell me and
> > I'll start watching it; show some continued motion and I'll spend some
> > time getting a buildbot going against the branch; show high quality
> > and I'll start pulling from it more and more frequently; show
> > incredibly quality and I'll suggest that the maintainer(s) get commit.
> > 
> >> For my part, I see that it could be helpful to let some patches/ideas get a
> >> shot at integration without having to endure the (necessarily) more 
> >> rigorous
> >> core commit trails.
> > 
> > Quality is important, and if this branch is created it needs to
> > maintain that quality. If this hypothetical branch is low-quality it's
> > just a different tool for a queue of un-reviewed patches, and I've
> > already got one of those. I'm not willing to compromise on quality: if
> > patches don't meet our standards, they don't go in.
> > 
> > Jacob
> 
> I fully agree regarding quality, my point being that this branch itself may
> not be "trunk ready" at any given time, but patches/pulls from it would be;
> quality of patches would obviously need to meet existing standards. Perhaps
> that distinction isn't helpful, necessary, or desirable.

I've been thinking of starting a proper contribution in django in a
similar way: a github repo with per-ticket branches that are trunk-ready
and regularly updated (rebased) against trunk until they are applied.

So far I've only done so for a pony of mine as a test, but as soon as
the ash cloud clears, I will look at existing tickets. Would this
approach be useful for core committers to pull patches from?

-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: High Level Discussion about the Future of Django

[Dennis Kaarsemaker]

On ma, 2010-04-05 at 23:25 +0800, Russell Keith-Magee wrote:

> I'll freely admit that despite the major improvements landing in 1.2,
> the development cycle itself hasn't been flawless. Hopefully I've been
> able to provide some explanation for why things ended up the way they
> did.

You have, thank you very much.

> So - tl;dr:
> 
>  * Yes, with hindsight, we probably should have cut a 1.1.2 release
>  * We probably should have cut that release somewhere around the start
> of March

Agreed.

>  * We're close enough to 1.2 that we're not going to cut a 1.1.X
> release until 1.2-final

Agreed again.

>  * Direct feedback from the #django and django-users trenches might
> have avoided this problem
>  * We'll try to do better next time. 

I will try to do better as well, bringing up often-reported problems on
the -developers mailing list.
-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: High Level Discussion about the Future of Django

[Dennis Kaarsemaker]

On ma, 2010-04-05 at 21:47 +0800, Russell Keith-Magee wrote:

> The bit that I have been engaging with is the discussion of (and
> apparent misconceptions around) Django's backwards compatibility
> policy, and our policies regarding support for older Python versions.

And I appreciate that you have done so, thanks!

> However, even these discussions have limited interest for me unless
> they rapidly converge on a *specific* criticism or problem that
> requires rectification. 

Not a criticism per se, but I am wondering why the next 1.1.x is
released alongside 1.2 instead of as a release on its own. I've yet
again seen a case of python 2.6.5 breaking django tests, so I would
welcome a new release of 1.1.x a bit sooner than 1.2, if only from a
#django support perspective.

-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: High Level Discussion about the Future of Django

[Dennis Kaarsemaker]

On ma, 2010-04-05 at 14:37 +0800, Russell Keith-Magee wrote:

> For some perspective - even though Python 3.1 is out, dropping support
> for Python 2.3 in Django 1.2 is being greeted as controversial in some
> circles because RedHat Enterprise Linux 5 is still officially
> supported by RedHat, and RHEL5 ships with Python 2.3.

Rhel 5 ships with 2.4, rhel 4 shipped with 2.3. I still have to use
django on the latter, so the support for 2.3 being dropped is an issue
for me. Then again, rhel 4 is positively ancient and I really should
move on :-)

-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Does Python 2.6.5 broke Django 1.1.1 Client Test?

[Dennis Kaarsemaker]

On ma, 2010-03-22 at 08:53 -0400, Karen Tracey wrote:
> On Mon, Mar 22, 2010 at 4:07 AM, Raffaele Salmaso
>  wrote:
> Marcob wrote:
> > Please, does anybody know which patch I need to apply to
> 1.1.1 to fix
> > this strange problem?
> 
> http://code.djangoproject.com/changeset/12807 ?
> 
> 
> No, turns out it was a change made farther back, and it was in fact a
> change specifically in response to the change in Python: 
> 
> http://code.djangoproject.com/changeset/11821

When can we expect to see this patch in a 1.1.x release? The problem is
coming up in #django suspiciously often (3 times in the last week so
far).

-- 
Dennis K.

They've gone to plaid!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Regarding httponly cookies

[Dennis Kaarsemaker]

On wo, 2010-03-17 at 11:10 -0700, Yuchen Zhou wrote:

> So does this ticket mean django now supports httponly cookies? And is
> it by default httponly?
> Or the application administrator has to turn it on?

The discussion on http://code.djangoproject.com/ticket/3304 indicates
that neither python nor django at the moment support it and that django
will need to implement its own cookie handling if it wants to continue
supporting python versions as old as 2.4.

There are patches attached to the issue, but none of those have been
applied to django yet.

-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

On ma, 2010-03-08 at 08:09 +0800, Russell Keith-Magee wrote:
> On Mon, Mar 8, 2010 at 7:56 AM, Dennis Kaarsemaker
> <den...@kaarsemaker.net> wrote:
> > I have now added tests and documentation. Comments are still welcome, I
> > have not received any feedback yet :(
> 
> Please don't take it personally -- it's just that we're just not
> really fielding new features at the moment. The attention of the core
> is on closing out bugs so we can push out the 1.2 final release.

Thanks for responding Russel. I know this is not new-feature time, so I
did not expect a detailed reply but hoped for a quick 'sounds good' or
'no way', which you've now given. 

I'll reply to your concerns, but feel free to not reply. I will bring it
up again at feature-adding time.

> On top of that - advertising that you've opened a ticket and uploaded
> a patch, but that the patch is "untested" isn't a great way to get
> attention. For future reference, a test is how you convince us that
> you're serious and that your code works. If you haven't provided
> tests, we have no way of knowing if the code works, or how thorough
> you have been in testing it.

Ok, I will remember that for the future.

> As some quick feedback -- the idea itself seems sound. I have minor
> concerns YAGNI concerns (is there really a need to differentiate
> between pre_save and pre_update on a field?), 

pre_save deals with instances, pre_update with a dict of changes applied
to a number of objects

> and I'm not completely
> sold on the classmethod for models (isn't that just a queryset update
> with filter(pk=X)?).

No, it is a classmethod because it is called once per queryset.update()
and not once per instance.

> However, I also haven't dug into the issue in any depth, so my initial
> reactions might be way off. I won't be looking seriously at any new
> features until the 1.3 timeframe; so all I can suggest is that you
> keep your patch warm, and when the time arrives, ping the list again.

Thanks, will do!
-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

I have now added tests and documentation. Comments are still welcome, I
have not received any feedback yet :(

On wo, 2010-03-03 at 19:00 +0100, Dennis Kaarsemaker wrote:
> I know that queryset.update does not call .save() for each instance and
> I know why. I even agree with it :)
> 
> However, I'd like to have a bit more control over what update() does,
> e.g. for auditing purposes. I know that I can simply write a few lines
> of code near every update() call to do what I want, but that violates
> DRY.
> 
> I have created ticket #13021 and uploaded a patch that adds a few new
> features:
> 
> * pre_update and post_update signals
> * a pre_update method for Field that does nothing
> * a pre_update method for DateField for auto_now magic
> * an update() method for Model that calls pre_update for all fields. 
>   This method is a classmethod
> * a patched QuerySet.update() that
>   - Sends the pre_update and post_update signals
>   - Calls the models update method to update the kwargs dict
> 
> The patch is untested, but should give a good idea of what I want to
> achieve. Is this approach suitable for inclusion in django? If so, I
> will complete the patch, add tests and documentation and will submit it
> for inclusion at the appropriate time.
> 
> Thanks in advance for considering and commenting,

-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

I know that queryset.update does not call .save() for each instance and
I know why. I even agree with it :)

However, I'd like to have a bit more control over what update() does,
e.g. for auditing purposes. I know that I can simply write a few lines
of code near every update() call to do what I want, but that violates
DRY.

I have created ticket #13021 and uploaded a patch that adds a few new
features:

* pre_update and post_update signals
* a pre_update method for Field that does nothing
* a pre_update method for DateField for auto_now magic
* an update() method for Model that calls pre_update for all fields. 
  This method is a classmethod
* a patched QuerySet.update() that
  - Sends the pre_update and post_update signals
  - Calls the models update method to update the kwargs dict

The patch is untested, but should give a good idea of what I want to
achieve. Is this approach suitable for inclusion in django? If so, I
will complete the patch, add tests and documentation and will submit it
for inclusion at the appropriate time.

Thanks in advance for considering and commenting,
-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Please apply fix for my pet bug

[Dennis Kaarsemaker]

Yes, this is a shameless request to get my pet bug fixed :)

A while ago I filed http://code.djangoproject.com/ticket/11448 -- this
is the only bug that makes me have to ship a custom django version with
my app, which I think is a shame.

The problem is that doing anything that calls Model._meta.init_name_map,
such as querying the model or defining a ModelForm that uses it, will
make adding additional ForeignKeys impossible.

The ticket includes a patch and a testcase, I believe that's all that's
needed for it to be applied. Can a developer please have a look at this
and make me happy? Thanks!

-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=.

Re: Proposal for __neq field lookup

[Dennis Kaarsemaker]

On di, 2009-10-20 at 16:09 +0200, Michael P. Jung wrote:

> Besides exclude(x=None).exclude(y=None).exclude(z=None) feels less
> intuitive to me than filter(x__neq=None, y__neq=None, y__neq=None).

That's what Q objects are for:

.filter(~Q(x=None),~Q(y=None),~Q(z=None))

or:

.filter(~(Q(x=None)|Q(y=None)|Q(z=none))
-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---