FWIW Ben, I had the same error, but under different circumstances
(your message below is the top google result for the error!). For me,
the problem was caused by a custom save() method in the model not
calling super().save(). Did you omit such a method in your gist.github
models?
On 6 September 20
On Sep 25, 8:02 am, tWoolie
wrote:
> I never saw that ticket. I've been looking at it purely from the
> perspective of trying to inject it into the model in my app to get
> around doing expensive filtering in my template.
> I see Jacob's point that saving a few chars in python is not worth it
> fo
(That's when somebody jumps into the conversation and feel as if he's half
naked wearing dirty underwear)
Hello,
just FYI, I've hacked a few lines of code that I use to have a simple way to
access all the fields on a model (including m2m):
https://github.com/magopian/django-inspect-model
On Sat, Sep 24, 2011 at 9:28 PM, Luke Plant wrote:
>
> I'm happy to be proved wrong, of course. Apache is very popular, though,
> so if its hard in Apache, it could be said to be hard full stop.
>
RequestHeader unset X-Forwarded-Protocol
Not precisely what I'd call hard.
>From a-business-that
On 26/09/11 12:45, Tom Evans wrote:
> On Sat, Sep 24, 2011 at 9:28 PM, Luke Plant wrote:
>>
>> I'm happy to be proved wrong, of course. Apache is very popular, though,
>> so if its hard in Apache, it could be said to be hard full stop.
>>
>
> RequestHeader unset X-Forwarded-Protocol
>
> Not pr
There is often a need to write model-independent Django templates. By
now, the only field name-dependent attribute in Django templates is
get_field_display, because the particular field names must be
hardcoded for each model.
What I propose is a universal filter which should provide human-
reada
Just my two cents worth, but I think something like this is such a 'per case
basis', that it probably shouldn't be included in the core.
Unless you can guarantee that all web application servers/load balancers are
going to correctly handle the header out of the box (i.e. inject/strip where
necessa
Ivan,
I completely agree that it would be useful to have something like this, as I
have some up against this *exact* same problem in the past.
However, when I raised it as an issue on IRC - the only response I got was
"stop putting your application logic into the templates" lol.
So, although I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/26/2011 06:16 AM, Cal Leeming [Simplicity Media Ltd] wrote:
> Unless you can guarantee that all web application servers/load balancers
> are going to correctly handle the header out of the box (i.e.
> inject/strip where necessary), then there's n
On Mon, Sep 26, 2011 at 5:39 PM, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/26/2011 06:16 AM, Cal Leeming [Simplicity Media Ltd] wrote:
> > Unless you can guarantee that all web application servers/load balancers
> > are going to correctly handle the header out
On Sep 20, 4:16 pm, Carl Meyer wrote:
>
> Yeah, this is confusing in our Trac UI. The "accept" radio button at the
> bottom assigns the ticket to you, it doesn't actually do anything with
> the triage state. To change the ticket from DDN to Accepted you'd use
> the dropdown next to "Triage Stage"
Hi,
On Monday, September 26, 2011 9:06:47 PM UTC+2, Brian Neal wrote:
>
> I'm not arguing it one way or
> another with respect to Django usage, I'm just explaining what I think
> the purpose of that state is in an out-of-the-box Trac install.
>
Jupp, that's the state now -- sadly code.djangopr
Hi all,
I finally got fed up with the common performance problem of ending up
doing O(n) DB queries when you need the (many) related objects of a list
of objects, and did something about it:
https://code.djangoproject.com/ticket/16937
I'm pretty sure the concept is something desirable, the probl
On Mon, Sep 26, 2011 at 9:50 PM, Luke Plant wrote:
> Hi all,
>
> I finally got fed up with the common performance problem of ending up
> doing O(n) DB queries when you need the (many) related objects of a list
> of objects, and did something about it:
>
> https://code.djangoproject.com/ticket/169
On 27/09/11 03:23, Alex Gaynor wrote:
> I'm not a fan of this, for a few reasons, firstly: because it feels
> wrong for a QuerySet to execute multiple queries. This isn't a deal
> breaker, just something that struck my conceptually initially. Second I
> disagree that it's difficult to do outside
Hi all,
We're a a group of students at UC Berkeley taking an open source class and
we've decided to contribute to Django.
We looked at the bug tracker but it seems a little disorganized and some of
the easier bug reports are kinda trivial.
Is there any suggestions on how do we start?
Thanks!
On Mon, Sep 26, 2011 at 11:10 PM, jaminw wrote:
> Hi all,
>
> We're a a group of students at UC Berkeley taking an open source class and
> we've decided to contribute to Django.
>
> We looked at the bug tracker but it seems a little disorganized and some of
> the easier bug reports are kinda triv
Hello (again),
seems my previous message got eaten up, so I'll try a repost :
I've done a small app that I use to inspect models, it lives here:
https://github.com/magopian/django-inspect-model
I'm afraid this isn't rocket science, and is probably very ugly. I'm using
the "inspect" module from
Great to hear you're getting involved!
Some things I'd like implemented in DJango involve reducing
build-setup environment and expanding project uses to the CMS markets
by incorporated DJango project distribution+setup.
For starters, I was thinking 3 installers (exe,rpm,deb) and a shell
script (s
19 matches
Mail list logo
