Using model classes in templates #16307

Hello all, I've had some troubles with default callables in FKs and tracked it down to one of my templates tags which returns a model class. I'm not sure if this is considered kosher or not so feel free comment on that too. In my template I have a something like: {{ my_project_lookup_class.cl

Re: Migrating to 1.4

Thanks for the heads-up. My 50k python lines project is still running 1.2.7 + #12823. For some reason this patch can't seem to be commited, despite being a potiential data-loss. I'm still worrying about migrating to 1.3.1! Best regards, Philippe On 14 March 2012 16:22, Dan Fairs wrote: > Hi, >

Ticket #12823

I have updated my patch for this old query bug versus current trunk. I've been happily using it for over a year in production, and was hoping someone higher up the foodchain would check it out for inclusion in the upcoming release. This bug is long-standing and silently produces broken queries, wh

Re: Towards a more friendly NoReverseMatch

+1 on this, been bitten repeatedly. I assume the url parser already "knows" this so this is mostly a matter of raising the appropriate exception. Bien cordialement, Philippe On 12 October 2011 17:13, Wilfred Hughes wrote: >> >    >>> reverse('i_dont_exist') >> >    NoReverseMatch: Reverse for

Re: RFC #12823

but I understand that'd be bad manners since I wrote the patch. Philippe On 16 December 2010 09:37, Harro wrote: > Made some comments about the bug and the patch. > The patch gives the right result, but the JOIN there is a bit weird. > > On Dec 15, 7:54 pm, Philippe Raou

Re: SQL join promotion as a result of querying for a NULL value

I too was rather surprised by this behavior. I have since changed my code to use exclude(related__field__isnull = False) instead of filter(related__field__isnull = True) to avoid this issue. I'm all for an API, but I'm not sure which would be best. Maybe filter(related__field__isnull_nopromote = T

RFC #12823

I have produced a patch for this [1] long-standing SQL bug. The SQL produced with the patch is correct AFAIK, but my understanding of the sql code is rather poor so I'm hoping that someone who knows better will give it a look. There might be a more correct/elegant way to fix this. [1] http://code

Re: Proposal for 1.3 - decoupling a few things in Django a bit.

My app does roughly the same thing and is organised as thus: - each module has its own app (invoices, emails, stuff_we_sell...). The app contains the models with most of the business logic and the managing views (for our own use) - a separate client access module that wraps around some of the mana

Re: default Model.all()?

y not familiar with caching and threading and thus fail to see how that breaks anything (vs using blogpost.comment_set.all in a template). Maybe you could you enlighten me ? Regards, Philippe On Thu, Oct 22, 2009 at 8:05 PM, Luke Plant wrote: > > On Thursday 22 October 2009 18:16:23 Philippe R

Re: default Model.all()?

While we're talking about that, is there a reason the default manager isn't iterable (default mapping to .all()) ? This is not as trivial as it sounds, because it means template writers need to be aware of which member of the class are managers and which are plain methods returning lists or query

Re: Is this true. that django really takes a lot of memory?

Hi, I did a reply on the post. Might be some time before it's approved. The gist is that yes it's that bad if you're using it naively. As long as you know what's gonna be loaded from the DB you can avoid those cases pretty easily. You can also check http://github.com/dcramer/django-idmapper/tree

Re: Usage of items() vs iteritems()

I'd venture that it's a simple oversight. items() is likely taking more memory in addition to being slower because it creates a list of the items while iteritems simply returns an iterator. On Mar 24, 9:51 am, David Cramer <[EMAIL PROTECTED]> wrote: > Ive been having to dig into code vs documenta

0.96.1 / 096-bugfixes

I was wondering why there is no 096-bugfixes branch. Does that reflect a policy change since previous versions ? Since 0.97 looks pretty far away with all the merging waiting to happen (queryset-refactor & newforms-admin at least), would it make sense to backport a few bugfixes and maybe a couple

Re: Call to Arms -- Caching Mechanisms

I'm too wasted to write a coherent answer, but I'd like to point out that http://code.djangoproject.com/ticket/17 has a patch for caching that has been refactored during the sprint. Regards, Philippe --~--~-~--~~~---~--~~ You received this message because you are

form_for_model arguments

Here are two quick suggestions: form_for_model in the trunk supports a 'fields' argument. What do you guys think about adding an 'exclude_fields' argument ? It is very handy when you want to have all but one or two fields from a model in a form. In the same vein, I have studied the queries genera