Re: select_related to work with backward relationships?

[Malcolm Tredinnick]

On Mon, 2009-03-23 at 21:45 -0400, George Vilches wrote:
> 
> On Mar 23, 2009, at 8:08 PM, Malcolm Tredinnick wrote:
> 
> > It is documented in that respect. In a couple of different Trac  
> > tickets
> > (since there are multiple issues: select related for reverse one-to- 
> > one,
> > which only isn't in 1.1-beta because I ran out of time to fix the  
> > patch,
> > and select-related for multi-valued relations).
> 
> I'll happily bring the patch up to date on #7270 for 1.1 if it's just  
> a matter of you running out of time.  You took over the ticket the day  
> I started looking back into it, so I let it be till I heard more from  
> you. :)


No, it's a bit more than that. I spent quite a bit of time looking at
this over the past week (I wanted to get it finished by yesterday
because I know of a bunch of high-volume places where it could be useful
for usre profiles). It seems to be a bit more intrusive than it needs to
be, but that's more of a gut feeling (which I trust) than anything
concrete yet. It also adds four new modules to the tests, when it seems
to only need to update one or two others (okay -- a rare case of a
complaint about "too much testing", but it's a little messy and just
placed a little strangely into the existing source).

Also, looking at it, the SQL it constructs isn't correct (I believe this
is also mentioned in a comment on the ticket somewhere). It isn't
promoting joins to outer joins all the time, which means results will be
omitted.

I do apologise, I realise I let you down here when you did so much work
on this initially. I have nothing to say to that. Will try to do better
next time. It got priorised lower than some things with greater impact.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: select_related to work with backward relationships?

[George Vilches]

On Mar 23, 2009, at 8:08 PM, Malcolm Tredinnick wrote:

> It is documented in that respect. In a couple of different Trac  
> tickets
> (since there are multiple issues: select related for reverse one-to- 
> one,
> which only isn't in 1.1-beta because I ran out of time to fix the  
> patch,
> and select-related for multi-valued relations).

I'll happily bring the patch up to date on #7270 for 1.1 if it's just  
a matter of you running out of time.  You took over the ticket the day  
I started looking back into it, so I let it be till I heard more from  
you. :)

George

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Django 1.1 beta 1 released

[Jacob Kaplan-Moss]

Hi all --

Tonight we've released Django 1.1 beta 1, the second in a series of
alpha and beta preview packages running up to the final Django 1.1
release, due mid-April. As always, alpha and beta packages are *not*
for production use, but if you'd like to try out the new features or
go bug-hunting in a safe environment, feel free to take it for a spin.

Download instructions are here:
http://www.djangoproject.com/download/

Blog post announcing the release is here:
http://www.djangoproject.com/weblog/2009/mar/23/11-beta-1/

Release notes are here:
http://docs.djangoproject.com/en/dev/releases/1.1-beta-1/

Enjoy!

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Django 1.1 beta 1 released

[Jacob Kaplan-Moss]

Hi all --

Tonight we've released Django 1.1 beta 1, the second in a series of
alpha and beta preview packages running up to the final Django 1.1
release, due mid-April. As always, alpha and beta packages are *not*
for production use, but if you'd like to try out the new features or
go bug-hunting in a safe environment, feel free to take it for a spin.

Download instructions are here:
http://www.djangoproject.com/download/

Blog post announcing the release is here:
http://www.djangoproject.com/weblog/2009/mar/23/11-beta-1/

Release notes are here:
http://docs.djangoproject.com/en/dev/releases/1.1-beta-1/

Enjoy!

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DDN on #9284

[Malcolm Tredinnick]

Hey Joseph,

On Mon, 2009-03-23 at 15:32 -0500, Joseph Kocherhans wrote:
> #9284 [1] Has a patch to make BaseModelFormSet call ModelForm.save()
> when saving objects rather than using completely custom code as it
> does now. I think this is the "right thing (tm)" to do, but it will
> break people's code who have overridden the formset's __init__ method
> and mucked around with the "initial" argument. I don't really feel bad
> about said breakage, because hey, you're messing with internals, you
> should know what you're doing.

I've looked at this briefly. I haven't got a strong opinion about the
effects of the backwards incompatibility yet (although I've been
thinking about it in odd moments since I saw you post that patch),
although your logic isn't totally from Outer Space.

The approach looks better. I'd be tempted to lift a couple of those
leading-underscore methods up to just being normal methods. Found myself
having to override a few of those things lately when wanting to use the
formset infrastructure in other ways. It won't kill us to allow inital-,
total- and management-forms getters to be overridden, I don't think.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: select_related to work with backward relationships?

[Malcolm Tredinnick]

On Mon, 2009-03-23 at 06:50 -0700, Jari Pennanen wrote:
> Found out that it doesn't work.
> 
> I think this should be documented that backwards relationships does
> *not* work in select_related, since I see no reason why it couldn't
> work, it might be tricky to implement, but I think it should be
> doable.

Seriously, if we documented everything that wasn't possible with Django,
the documentation would be a couple of million words long. There's
nothing that says select_related() does work with reverse relations and
if people are going to make assumptions, that's their problem.

> 
> If it were documented, someone might get idea to improve django and
> make patch for it...

It is documented in that respect. In a couple of different Trac tickets
(since there are multiple issues: select related for reverse one-to-one,
which only isn't in 1.1-beta because I ran out of time to fix the patch,
and select-related for multi-valued relations).

Regards,
Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Administrative note about 1.1 beta

[Jacob Kaplan-Moss]

Hi folks --

We'll be releasing 1.1 beta 1 shortly; look for the announcement from James.

However, there are two tickets that didn't make it into the release
that we're going to grant a special dispensation from feature freeze:

First is #3182, queryset.update()/update_or_create(). This didn't get
a firm decision made on time, and it seems silly to punt just because
nobody made a choice one way or the other. We should either commit the
patch, or mark the ticket wontfix. We're going to give a couple more
days to try to find consensus before Adrian or I rule by fiat one way
or the other.

Second is #9977, the work Luke's been doing on CSRF. This is an
important security feature, and one that's important to get right.
Luke's got this work essentially done today, but security work like
this deserves a couple extra days of review before it goes in.

For these reasons, we'll be releasing 1.1 beta 1 without these
features, but we'll turn around and ship a beta 2 in a three/four days
with these decisions made. No other features will be allowed to sneak
into this second beta; it's purely a bit of waiting/decision for these
two outstanding issues.

Thanks to all for the great work on 1.1 beta, and I'm looking forward
to similar work as we close in on the final release.

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #9282 (comment moderation features) and Akismet removal

[Russell Keith-Magee]

On Tue, Mar 24, 2009 at 2:23 AM, Eric Florenzano  wrote:
>
> The Akismet module seems to me to be similar to a Memcached cache
> backend.  Yes, it's coupled to a single implementation, but it's the
> canonical implementation--note that the only competitor, TypePad
> AntiSpam [1], is "100% Akismet API compatible".
>
>> James, this is something that can be added later. This is progressive
>> enhancement of the functionality and *if* (not a given) we take what's
>> in #9282 now without blocking on every feature that might be possible or
>> popular, it won't be a shame. It isn't a half-baked implementation, it's
>> just leaving the door open for more additions in the future.
>
> I don't really understand this argument.  Maybe I'm not parsing it
> correctly, but I read this as "Your implementation is good, but let's
> not add it now so that we can add it later", which seems a bit
> strange.

The argument is "We can take what's in #9282 now without blocking
future development paths". #9282 doesn't currently contain the Akismet
backend, but it isn't "half baked" as a result - we can add Akismet
support as future enhancement.

The features of #9282 are a slam dunk good idea in and of themselves.
Akismet support is possibly a good idea, but warrants more discussion
to determine if we want to get into that particular game. Given the
pending deadlines, it's not worth letting the need for discussion hold
off committing what we already have in #9282.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

DDN on #9284

[Joseph Kocherhans]

#9284 [1] Has a patch to make BaseModelFormSet call ModelForm.save() when
saving objects rather than using completely custom code as it does now. I
think this is the "right thing (tm)" to do, but it will break people's code
who have overridden the formset's __init__ method and mucked around with the
"initial" argument. I don't really feel bad about said breakage, because
hey, you're messing with internals, you should know what you're doing.
Joseph

[1] http://code.djangoproject.com/ticket/9284

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

[Collin Grady]

On Mon, Mar 23, 2009 at 12:44 AM, Ivan Sagalaev
 wrote:
> I'd like to chime in with another point of view. Not my own, I was just
> in a discussion about it in our local forums and I don't want the idea
> to vanish.
>
> A person there wanted an `update()` method too but not behaving like you
> show. Instead he wanted it to update *just* the fields passed as
> arguments. I.e. it should be equivalent to this:

So more like http://code.djangoproject.com/ticket/4102 then ? :)

-- 
Collin Grady

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

CSRF template tag patch done

[Luke Plant]

Hi all,

The patch has been added to:

  http://code.djangoproject.com/ticket/9977

It includes tests, docs etc - I think it is complete.  Other notes are 
below (some of this would need to be prominently noted in the release 
notes).

I don't know if this is too late for the beta.  Since I guess we are 
working on US time, and I'm GMT, I'm guessing I may to have to leave 
this to one of the other committers.  I'll check email before midnight 
GMT and hang out on IRC.

Outline
===

The approach:
 - add a template tag to all POST forms.  This requires loading the
   csrf template tag library, and also requires using a context
   processor to get the token.  

 - use CsrfViewMiddleware to filter out requests that don't have the
   token.

All existing contrib apps use RequestContext, which has made the 
changes to them minimal (template only, and settings update).

Thanks to bthomas, Rob Hudson for initial patch.

Testing done


I've added tests for template tag etc., there was already pretty 
exhaustive testing for the middleware.

The middleware is not enabled for the test suite, so shouldn't cause 
any complications.

I've manually tested some views in the admin, but I haven't tested all 
the contrib apps, because of the time it would take to set up a 
harness for testing them.  I believe the existing test suite should 
have caught any basic rendering errors in the templates due to typos. 
The biggest problem might be that some contrib views don't actually 
use RequestContext (I think I checked this, but may have missed some).

Other features
==

When the middleware rejects a request, you can completely customise 
the page that is sent back (goodbye to the unfriendly '403 Forbidden' 
page), by setting the CSRF_FAILURE_VIEW setting to provide your custom 
view.

Upgrading
=

Unlike what was committed last week, this patch *requires* changes to 
project settings in order for the admin (and other contrib apps) not 
to break.  It could be considered backwards incompatible for this 
reason, but it is not an *API* change, just changes to settings.

The following things must be done:

 - django.contrib.csrf added to INSTALLED_APPS (for template tag)

 - django.contrib.csrf.middleware.CsrfViewMiddleware added to
   MIDDLEWARE_CLASSES (or the existing CsrfMiddleware replaced with
   CsrfViewMiddleware)

 - django.contrib.csrf.context_processors.csrf added to
   TEMPLATE_CONTEXT_PROCESSORS

 - Any existing apps should be upgraded to use the {% csrf_token %}
   method.  Alternatively (but not recommended), the existing
   CsrfMiddleware or CsrfResponseMiddleware can be used to cover those
   apps.

 - Obviously (but worth mentioning), if people have overridden
   the affected templates for any contrib apps, they may need
   updating.  This could be quite a bit of work in some cases, I
   imagine.  I think that the above solution of using 
   CsrfResponseMiddleware until the updates are done will also
   work in this case.

I don't think the above is that complicated, and compared to the 
alternatives that have been proposed, the changes are far less 
intrusive.  But obviously things can go wrong.  To see the impact of 
various mistakes, I've outlined a number of scenarios below, it's up 
to you to decide how serious these things are.  But if we don't do it 
now, we'll have to either suffer the existing response re-writing or 
have the admin vulnerable to CSRF by default for *another* release. 

Scenario 1
--
Developer doesn't bother to read release notes and do any of the above 
updates.

Result: admin app and other contrib apps break immediately (i.e. 
templates won't render), due to lack of 'django.contrib.csrf' in 
INSTALLED_APPS, causing {% load csrf %} to fail.


Scenario 2
--
Developer adds django.contrib.csrf to INSTALLED_APPS, but doesn't add 
the csrf context processor to TEMPLATE_CONTEXT_PROCESSORS.

Result: the admin app (etc.) will break - it will render, but you will 
get 403s if you make any POST requests.  If DEBUG = True, the 
developer will get a warning informing him of the problem.


Scenario 3
--
As in (2), but the developer has 'CsrfMiddleware' or 
'CsrfResponseMiddleware' installed.  This might be accidental, or 
because the developer needs the response re-writing middleware for 
other apps.

Result: admin etc. will work fine.  If DEBUG = True, the developer 
will get a warning informing him of the problem.

Scenario 4
--
The developer adds all settings correctly but doesn't remove 
CsrfMiddleware/CsrfResponseMiddleware.

This might be accidental, or because the developer needs the response 
re-writing middleware for other apps.

Result: admin will work fine.  The CSRF token will get inserted twice, 
but this is harmless (it's not even invalid HTML).

(We could fix the double insertions and performance hit by adding 
@csrf_response_exempt to relevant views in contrib, if we thought it 
was worth it).

Scenario 5
--

Re: #9282 (comment moderation features) and Akismet removal

[Waylan Limberg]

On Mon, Mar 23, 2009 at 1:23 PM, Eric Florenzano  wrote:
>
>> James, this is something that can be added later. This is progressive
>> enhancement of the functionality and *if* (not a given) we take what's
>> in #9282 now without blocking on every feature that might be possible or
>> popular, it won't be a shame. It isn't a half-baked implementation, it's
>> just leaving the door open for more additions in the future.
>
> I don't really understand this argument.  Maybe I'm not parsing it
> correctly, but I read this as "Your implementation is good, but let's
> not add it now so that we can add it later", which seems a bit
> strange.
>

I'm a little confused about the disagreement here. Perhaps I'm wrong,
but I get the sense that people are asking for two different things.

1. It seems that some are expecting the base CommentModerator to use
Akismet by default. That is a bad idea IMO. The patch as-is is correct
here.

2. While others are expecting a subclass of CommentModerator that uses Akismet.
Whether that happens or not, I don't really care. But whether it
happens when this patch is committed or later shouldn't really effect
whether this patch is ready or not.

Btw, while we're on the subject, this (hopefully option 2 above) would
make implementing Django-Spambayes [1] (a comment filter built on top
of the SpamBayes email filter) easier - with one exception. SpamBayes
is a training system. For the system to work, it needs to be trained
with both "ham" and "spam". Then there is the third state "unsure"
which goes into moderation. The user should then be able to move a
comment between any of those 3 states (retraining the system with each
move). Having only a two state system ("ham" and "unsure") with the
"spam" automatically deleted makes this kind of hard. I realize I
should be able to alter that in a subclass, but it would be nice if
the base class at least considered that a subclass might want to act
that way.

Perhaps an attribute on the class called "delete_spam" (or whatever
color you want to paint that bikeshed) which turned on or off
automatic deleting of unwanted messages. So setting "delete_spam" to
True would get the same behavior we have now while setting it to False
would leave the message in the db, set "is_public" to False, but also
recognize that it has already been moderated (I believe
`comment.is_removed = True` does that).

[1]: http://code.google.com/p/django-spambayes/
-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #9282 (comment moderation features) and Akismet removal

[Eric Florenzano]

The Akismet module seems to me to be similar to a Memcached cache
backend.  Yes, it's coupled to a single implementation, but it's the
canonical implementation--note that the only competitor, TypePad
AntiSpam [1], is "100% Akismet API compatible".

> James, this is something that can be added later. This is progressive
> enhancement of the functionality and *if* (not a given) we take what's
> in #9282 now without blocking on every feature that might be possible or
> popular, it won't be a shame. It isn't a half-baked implementation, it's
> just leaving the door open for more additions in the future.

I don't really understand this argument.  Maybe I'm not parsing it
correctly, but I read this as "Your implementation is good, but let's
not add it now so that we can add it later", which seems a bit
strange.

Thanks,
Eric Florenzano

[1] http://antispam.typepad.com/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: select_related to work with backward relationships?

[Alex Gaynor]

On Mon, Mar 23, 2009 at 9:50 AM, Jari Pennanen wrote:

>
> Found out that it doesn't work.
>
> I think this should be documented that backwards relationships does
> *not* work in select_related, since I see no reason why it couldn't
> work, it might be tricky to implement, but I think it should be
> doable.
>
> If it were documented, someone might get idea to improve django and
> make patch for it...
> >
>
There was a discussion of this on Django-users a few weeks ago, the general
sentiment is "patches welcome" for now.  The most important thing is to make
sure you're only returning N + K results, instead of N * K.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: select_related to work with backward relationships?

[Jari Pennanen]

Found out that it doesn't work.

I think this should be documented that backwards relationships does
*not* work in select_related, since I see no reason why it couldn't
work, it might be tricky to implement, but I think it should be
doable.

If it were documented, someone might get idea to improve django and
make patch for 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
-~--~~~~--~~--~--~---

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

[Tai Lee]

Are the objections being raised for `update()` equally applicable to
`update_or_create()`?

I would have thought that a name-space clash for this method on the
objects manager would have been a non-issue, as would any confusion
about the use of `force_update` and `force_create` internally (as they
are implied in the method name, they should be used internally for
each respective option).

I agree about the `default` name mis-match, but I can easily live with
that as it provides the same interface as `get_or_create()`.

Cheers.
Tai.


On Mar 23, 10:54 pm, Russell Keith-Magee 
wrote:
> On Mon, Mar 23, 2009 at 7:57 AM, Malcolm Tredinnick
>
>  wrote:
>
> > Kind of disappointed that none of the other "commit at will" people have
> > chimed in on this one (Adrian? Jacob? Russell? Bueller?...) I suspect
> > I'm going to lose, but I'd genuinely like to know that there's something
> > more than apathy behind the approval to add this.
>
> I'm -0, for mostly the same reasons as Malcolm.
>
>  * "fairly common" is hard to quantify, and the code that is being
> replaced isn't that hard to hand-roll as an end-user.
>  * If we include it, there's a backwards incompatibility issue to deal with.
>  * My goat (or is that pony?) entrails agree with Malcolm's
> predictions of "what about insert()/when to use force_update"
> discussions.
>
> My opinion on the 'code cleanliness' issue is acutally the opposite to
> Jacob - I actually prefer the obj.x=val; obj.save(force_update=True)
> version, for "explicit over implicit" reasons. However, as Jacob
> notes, this is a beauty in the eye of the beholder thing.
>
> I also have a slight problem with update_or_create method as
> described. For me, 'default' implies that any existing value will take
> precedence, but in update_or_create, the 'defaults' are effectively
> the new values. This is a bit of a bikeshed thing, but it does grate.
>
> However, I don't have any particularly compelling reason to _not_
> include this feature. My -0 is purely my perception of the balance of
> benefits vs risks, but it's a pretty fine balance. I won't lose much
> sleep over this either way.
>
> Russ %-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: %ifequal - what am I missing here?

[nwalt...@sprynet.com]

Thanks Malcom, you got me on the right track.  I was apparently
comparing two different objects instead of strings.  User was of type
db.UserProperty().

The following worked:

 {%ifequal conference.userAdded.__str__ user.email %}

Thanks again,
Neal Walters
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

select_related to work with backward relationships?

[Jari Pennanen]

Hello!

class City(models.Model):
# ...

class Person(models.Model):
# ...
hometown = models.ForeignKey(City, null=True, blank=True)

class Book(models.Model):
# ...
author = models.ForeignKey(Person)

# Can I cache Persons and Books too when getting City? After all there
is backwards relation City.person_set...
City.objects.select_related() # Doesn't work.
City.objects.select_related('person_set') # Doesn't work.

# Is there some reason this doesn't work when using backwards
relations?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

[Ivan Sagalaev]

Malcolm Tredinnick wrote:
> On Mon, 2009-03-23 at 10:44 +0300, Ivan Sagalaev wrote:
>> Looks like a "+0" useful API wrapper around direct calling of 
>> _default_manager.
> 
> Would they also like a stable and saddle with that pony?

Actually, this very concept has been somewhat explained to the guy [1] :-).


[1]: http://softwaremaniacs.org/forum/django/10090/#45895

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #9282 (comment moderation features) and Akismet removal

[Russell Keith-Magee]

On Mon, Mar 23, 2009 at 11:41 AM, Malcolm Tredinnick
 wrote:
>
> On Sun, 2009-03-22 at 21:29 -0500, James Bennett wrote:
>> On Sun, Mar 22, 2009 at 9:20 PM, Justin Lilly  wrote:
>> > My thoughts are that while akismet is the current gold standard, it
>> > should be replaceable with another, user-defined, backend if you so
>> > choose. Another that comes to mind is http://stupidfilter.org/main/
>> > which attempts to tell if something is stupid, rather than spam.
>>
>> Well, it'd be easy enough to simply write and bundle a one-off
>> subclass that does Akismet, and people can use that. Then if something
>> else wins the market over, it's easily replaceable. I'd just like to
>> have some sort of ready-made option for this since I'm sure it's
>> something a lot of people are going to want from a comment-moderation
>> system.
>
> James, this is something that can be added later. This is progressive
> enhancement of the functionality and *if* (not a given) we take what's
> in #9282 now without blocking on every feature that might be possible or
> popular, it won't be a shame. It isn't a half-baked implementation, it's
> just leaving the door open for more additions in the future.

Agreed. +1.

Russ %-)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

[Russell Keith-Magee]

On Mon, Mar 23, 2009 at 7:57 AM, Malcolm Tredinnick
 wrote:
>
> Kind of disappointed that none of the other "commit at will" people have
> chimed in on this one (Adrian? Jacob? Russell? Bueller?...) I suspect
> I'm going to lose, but I'd genuinely like to know that there's something
> more than apathy behind the approval to add this.

I'm -0, for mostly the same reasons as Malcolm.

 * "fairly common" is hard to quantify, and the code that is being
replaced isn't that hard to hand-roll as an end-user.
 * If we include it, there's a backwards incompatibility issue to deal with.
 * My goat (or is that pony?) entrails agree with Malcolm's
predictions of "what about insert()/when to use force_update"
discussions.

My opinion on the 'code cleanliness' issue is acutally the opposite to
Jacob - I actually prefer the obj.x=val; obj.save(force_update=True)
version, for "explicit over implicit" reasons. However, as Jacob
notes, this is a beauty in the eye of the beholder thing.

I also have a slight problem with update_or_create method as
described. For me, 'default' implies that any existing value will take
precedence, but in update_or_create, the 'defaults' are effectively
the new values. This is a bit of a bikeshed thing, but it does grate.

However, I don't have any particularly compelling reason to _not_
include this feature. My -0 is purely my perception of the balance of
benefits vs risks, but it's a pretty fine balance. I won't lose much
sleep over this either way.

Russ %-)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

[Malcolm Tredinnick]

On Mon, 2009-03-23 at 10:44 +0300, Ivan Sagalaev wrote:
[...]
> A person there wanted an `update()` method too but not behaving like you 
> show. Instead he wanted it to update *just* the fields passed as 
> arguments. I.e. it should be equivalent to this:
> 
>  def update(self, **kwargs):
>  self._default_manager.filter(pk=self.pk).update(**kwargs)
> 
> Looks like a "+0" useful API wrapper around direct calling of 
> _default_manager.

Would they also like a stable and saddle with that pony?

It's the same net effect as the method Gary is proposing (providing the
object already exists in the database). Even more identical when we add
the optional ability to only update the fields that have changed. It's
already only a one-liner, as you notice, if somebody wants to do it
right now.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: django calls several views at once.

[igor.potapenko]

Sorry for many-words and many of unusable infromation.

In my example there's calling one view(cat2_view), which just print
all Cats objects(in it not creating any objects!).

After calling that view - one object creates.
I say more. It suppress exeption from it. I had a concern in it.

It must be admitted that, I don't know way to call view-method without
'manage.py runserver'. I can't find information about it.
Therefor I post so huge message.

However, I found, what's wrong(just add "print request.path_info"
statement to django.core.handler.base).
My brower try request /favicon.ico and second view's called in same
time.


Sorry to trouble you =)

On 23 мар, 01:42, Malcolm Tredinnick  wrote:
> On Sat, 2009-03-21 at 23:18 -0700, igor.potapenko wrote:
> > Is it normal behavior?
> > In example below, I try to call myapp2.view.cat2_view through "/a/"
> > url-path. It's calling, however another views myapp1.view.cat1_viewis
> > also calling with it at same time.
>
> Django doesn't call more than one view for any particular URL pattern.
> The code works out a function to call, calls it and then returns the
> response.
>
> If you want more help understanding what's going in your particular
> case, please post to django-users (this isn't a bug in Django, it's a
> misunderstanding or a bug in your code -- hard to tell which at the
> moment).
>
> If you want help with this, I'd suggest working hard on trimming down
> the information you're posting to explain just the problem. The output
> of syncdb doesn't really matter here. The output from runserver isn't
> too informative, since we don't know what you did to trigger those
> lines, whether they all come from what you consider a single request or
> what.
>
> Your views are useful to see, the small model is too. The missing bit is
> what URL you are requesting and what happened when you did that. If you
> trim your explanation down to those points when you post to
> djanog-users, somebody might well be able to help you.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

[Ivan Sagalaev]

Jacob Kaplan-Moss wrote:
> I've mostly stayed out because it's not something I feel strongly
> about, but I am +0 on the change. The reason I don't much care is that
> it really comes down to a lines of code argument; is::
> 
> obj.update(x=1, y=2, z=3)
> 
> really that much "better" than::
> 
> obj.x = 1
> obj.y = 2
> obj.z = 3
> obj.save()

I'd like to chime in with another point of view. Not my own, I was just 
in a discussion about it in our local forums and I don't want the idea 
to vanish.

A person there wanted an `update()` method too but not behaving like you 
show. Instead he wanted it to update *just* the fields passed as 
arguments. I.e. it should be equivalent to this:

 def update(self, **kwargs):
 self._default_manager.filter(pk=self.pk).update(**kwargs)

Looks like a "+0" useful API wrapper around direct calling of 
_default_manager.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---