Re: Signals for ManyToMany relations question

Sorry for the confusion but I sent the original link from my mobile handset which isn't great for copying/pasting/etc. In another post, we were discussing the issue of ManyToMany updates [1] and how the signal handler for a model X that has a ManyToManyField to Y will _not_ have an updated Y.

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Fri, Dec 4, 2009 at 12:19 PM, mattimust...@gmail.com wrote: > > > On Dec 4, 2:56 pm, Russell Keith-Magee wrote: >> On Fri, Dec 4, 2009 at 11:46 AM, mattimust...@gmail.com >> >> >> >> >> >> wrote: >> >> > On Dec 4, 2:33 

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Dec 4, 2:56 pm, Russell Keith-Magee wrote: > On Fri, Dec 4, 2009 at 11:46 AM, mattimust...@gmail.com > > > > > > wrote: > > > On Dec 4, 2:33 am, Russell Keith-Magee wrote: > >> Hi all, > > >> I've been looking at

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Fri, Dec 4, 2009 at 11:46 AM, mattimust...@gmail.com wrote: > > > On Dec 4, 2:33 am, Russell Keith-Magee wrote: >> Hi all, >> >> I've been looking at ticket #7052 again. I've got a draft patch up on >> Trac, and I'd like feedback on the

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Dec 4, 2:33 am, Russell Keith-Magee wrote: > Hi all, > > I've been looking at ticket #7052 again. I've got a draft patch up on > Trac, and I'd like feedback on the approach. > > Previously, I've been advocating the approach of embedding queries > into the

Re: Signals for ManyToMany relations question

On Fri, Dec 4, 2009 at 10:23 AM, Ryan K wrote: > This message is in regards to the patch on Ticket 5390 (http:// > code.djangoproject.com/ticket/5390). I know that the period for > changes is closed The period for changes isn't closed at all - we're in the feature

Signals for ManyToMany relations question

This message is in regards to the patch on Ticket 5390 (http:// code.djangoproject.com/ticket/5390). I know that the period for changes is closed but why shouldn't the current API just work. It seems like a special case is being treated very differently but since there relation is already implied

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 12:20 AM, Waldemar Kornewald wrote: > Hi Russell, > I just noticed a simple documentation bug. See the comment at the > bottom of this page: > http://github.com/alex/django/commit/aabfee1571d378dd3b7550573e900850d13e1b9b You are correct. Thanks for

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Fri, Dec 4, 2009 at 7:03 AM, Luke Plant wrote: > On Thursday 03 December 2009 15:33:44 Russell Keith-Magee wrote: > >> So, I've taken a different approach with this new patch. The new >> approach is much simpler and more explicit than the last. Rather >>  than trying to

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Thursday 03 December 2009 15:33:44 Russell Keith-Magee wrote: > So, I've taken a different approach with this new patch. The new > approach is much simpler and more explicit than the last. Rather > than trying to embed a query into the serialization language, I've > taken a step back and

Re: Multiple database support: Request for feedback and testing

Hi Russell, I just noticed a simple documentation bug. See the comment at the bottom of this page: http://github.com/alex/django/commit/aabfee1571d378dd3b7550573e900850d13e1b9b Also, I hope you won't define an API for overriding the query class in the multi-db branch. We'll most likely have to

Multiple database support: Request for feedback and testing

Hi all, Alex Gaynor's GSoC project to add multiple database support to Django is on the final straight. The only piece of the puzzle that is left is updating contrib.gis - but this hopefully won't require any major changes outside of the gis tree itself. Therefore, I'd like to call for feedback

Re: Session/cookie based messages (#4604)

On Thu, Dec 3, 2009 at 10:23 AM, Luke Plant wrote: > On Thursday 03 December 2009 14:18:10 Waylan Limberg wrote: > >> Looking though this patch I couldn't help but notice the new >> get_messages function. What if a project has neither the >> MessageMiddleware nor the

#7052 - Fixing serialization for contrib.contenttypes and contrib.auth

Hi all, I've been looking at ticket #7052 again. I've got a draft patch up on Trac, and I'd like feedback on the approach. Previously, I've been advocating the approach of embedding queries into the serialization syntax - essentially, interpreting dictionaries in JSON (and equivalent in other

Re: Session/cookie based messages (#4604)

On Thursday 03 December 2009 14:18:10 Waylan Limberg wrote: > Looking though this patch I couldn't help but notice the new > get_messages function. What if a project has neither the > MessageMiddleware nor the contrib.auth app enabled? Sure a reusable > app could catch the error, but that error

Re: SMTPConnection DeprecationWarning

On Thu, Dec 3, 2009 at 11:05 PM, Luke Plant wrote: > On Thursday 03 December 2009 14:36:42 Russell Keith-Magee wrote: > >> > Also, I think it ought to be noted (along with a few other >> > things) in the "Features deprecated in 1.2" section of >> > docs/releases/1.2.txt >>

Re: SMTPConnection DeprecationWarning

On Thursday 03 December 2009 14:36:42 Russell Keith-Magee wrote: > > Also, I think it ought to be noted (along with a few other > > things) in the "Features deprecated in 1.2" section of > > docs/releases/1.2.txt > > Yes it should - but this time, in my defense, the 1.2 release notes > didn't

Re: Session/cookie based messages (#4604)

On Thu, Dec 3, 2009 at 9:18 AM, Waylan Limberg wrote: > Looking though this patch I couldn't help but notice the new > get_messages function. What if a project has neither the > MessageMiddleware nor the contrib.auth app enabled? Sure a reusable > app could catch the error, but

Re: SMTPConnection DeprecationWarning

On Thu, Dec 3, 2009 at 10:24 PM, Luke Plant wrote: > Hi all, > > With the addition of the configurable email backend functionality, > SMTPConnection is raising a DeprecationWarning.  Shouldn't this be a > PendingDeprecationWarning according to our procedure? Yes, it

SMTPConnection DeprecationWarning

Hi all, With the addition of the configurable email backend functionality, SMTPConnection is raising a DeprecationWarning. Shouldn't this be a PendingDeprecationWarning according to our procedure? Also, I think it ought to be noted (along with a few other things) in the "Features deprecated

Re: Session/cookie based messages (#4604)

On Thu, Dec 3, 2009 at 1:38 AM, Tobias McNulty wrote: > Latest patch, including fail_silently, is up for review: > > http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-e4da706e1152.diff > Looking though this patch I couldn't help but notice the

Re: Session/cookie based messages (#4604)

It's also a good thing, I realized last night, because it means one can use messages from a reusable app without requiring that all projects using the app enable messages. Cheers, Tobias Sent from a mobile phone, please excuse any typos. On Dec 3, 2009 6:25 AM, "Russell Keith-Magee"

Re: Session/cookie based messages (#4604)

Could we not also provide the convenience request.messages.* functions in the middleware that simply wrap the "real" functions? While I understand the need for the others, and agree with their use throughout the Django codebase, I also agree with Alex that they just read better, and I'd prefer to

Re: Session/cookie based messages (#4604)

On Thu, Dec 3, 2009 at 2:39 PM, Alex Gaynor wrote: > On Thu, Dec 3, 2009 at 12:58 AM, Tobias McNulty > wrote: >> >> >> On Tue, Dec 1, 2009 at 4:35 PM, Luke Plant wrote: >>> >>> I just converted some code, and the API seems

Re: Problem with history view in admin page

On Thu, Dec 3, 2009 at 12:59 PM, Mario Briggs wrote: > Russ, > > I dont agree to the *it works* theory here - Ian rightly said 'If you > ask me, > anybody foolish enough to use a TextField as a primary key deserves > what they get' and you agreed  'Your comment about