Re: select_related to work with backward relationships?

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

Re: select_related to work with backward relationships?

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

Django 1.1 beta 1 released

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

Django 1.1 beta 1 released

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

Re: DDN on #9284

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

Re: select_related to work with backward relationships?

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

Administrative note about 1.1 beta

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

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

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

DDN on #9284

#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

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

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

CSRF template tag patch done

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

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

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

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

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

Re: select_related to work with backward relationships?

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,

Re: select_related to work with backward relationships?

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

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

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

Re: %ifequal - what am I missing here?

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

select_related to work with backward relationships?

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

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

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

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

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,

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

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

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

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): >

Re: django calls several views at once.

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

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

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