"@cache_page" bug...
jedie
In the docu there ware two syntax for a "per-view cache":
"""
def my_cool_view(request):
# cool processing
slashdot_this = cache_page(slashdot_this, 60 * 15)
"""
or
"""
@cache_page(60 * 15)
def my_cool_view(request):
# cool processing
"""
see: http://www.djangoproject.com/documentation/cache/#the-per-view-cache
Both syntax version doesn't work yet, because of this Bug:
http://code.djangoproject.com/ticket/1015
The Bug is opened 2 years ago. Two years! And this ticket has a work-a-
round that works:
"""
@cache_page
def my_cool_view(request):
# cool processing
"""
I fall into this bug trap, because i have used the code from the
documentation. If you search the maillinglist, you can see, that other
users are falled into the same trap.
I have made a ticket, that the docu should be changed (insert a
comment and/or insert the work-a-round):
http://code.djangoproject.com/ticket/4649
This ticket is closed ("invalid")...
I think that is not the best way, to handle those things.
--
Mfg.
Jens Diemer
----
A django powered CMS: http://www.pylucid.org
SmileyChris
In that ticket I kinda agree with anonymous (who I'm guessing was
jedie). That ticket has a patch two months old, and since it's not
that critical it could sit there for much longer. Well maybe not in
this case, now it has got some attention.
It's just a fact that documentation tickets get fixed *much* faster
than ones that go into the abyss of design decision (or accepted,
even).
Documentation should be kept up to date even if there is a bug - it's
easy to update it again when the main ticket is fixed.
Malcolm Tredinnick
> I should really reply here rather than in the ticket:
>
> In that ticket I kinda agree with anonymous (who I'm guessing was
> jedie). That ticket has a patch two months old, and since it's not
> that critical it could sit there for much longer. Well maybe not in
> this case, now it has got some attention.
>
> It's just a fact that documentation tickets get fixed *much* faster
> than ones that go into the abyss of design decision (or accepted,
> even).
Documentation changes that are made to accommodate buggy behaviour
should never be made. I don't think we have a habit of doing that. I
certainly try to close all such tickets, indicating that the root cause
should be fixed. Documenting a bug is a way of not fixing the bug. If
somebody feels so strongly that this should be changed, then they do
best by addressing the root cause. Raising a query about #1015 would be
an appropriate way forward. Opening a ticket to document the bug is not.
>
> Documentation should be kept up to date even if there is a bug - it's
> easy to update it again when the main ticket is fixed.
Strongly disagree, unless there's no forseeable way the bug can be
fixed. All the incentive to fix the problem goes away once the
workaround becomes officially documented. That is why portions of Django
are not yet documented, because they aren't necessarily stabilised
and/or likely to change (generic relations, comments, ...). Work on
cause, not the symptom.
Regards,
Malcolm
SmileyChris
wrote:
> > Documentation should be kept up to date even if there is a bug - it's
> > easy to update it again when the main ticket is fixed.
>
> Strongly disagree, unless there's no forseeable way the bug can be
> fixed. All the incentive to fix the problem goes away once the
> workaround becomes officially documented. That is why portions of Django
> are not yet documented, because they aren't necessarily stabilised
> and/or likely to change (generic relations, comments, ...). Work on
> cause, not the symptom.
While I see your point, I'm not convinced. People often come asking
about progress on tickets similar to this one - the answer is usually
"we'll get around to it, it's not a priority ticket". So the
documentation doesn't get updated, and people are left scratching
their heads as to why officially documented behaviour doesn't work.
In this specific instance, the behaviour isn't exactly "buggy" (even
if it is different) - I'd argue that the documentation is just plain
wrong. cache_page works and documented *except* for the 2.4 decorator
example. Sure, if we want to change the behaviour, let's do it. But
while it's not changed, why not just fix the documentation.
In the end, meh. I guess it's just a difference of opinion. I see
keeping accurate documentation as more important (and I don't think
incentives disappear because of documentation).
Malcolm Tredinnick
> On Jun 23, 1:55 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
> > > Documentation should be kept up to date even if there is a bug - it's
> > > easy to update it again when the main ticket is fixed.
> >
> > Strongly disagree, unless there's no forseeable way the bug can be
> > fixed. All the incentive to fix the problem goes away once the
> > workaround becomes officially documented. That is why portions of Django
> > are not yet documented, because they aren't necessarily stabilised
> > and/or likely to change (generic relations, comments, ...). Work on
> > cause, not the symptom.
>
> While I see your point, I'm not convinced. People often come asking
> about progress on tickets similar to this one - the answer is usually
> "we'll get around to it, it's not a priority ticket". So the
> documentation doesn't get updated, and people are left scratching
> their heads as to why officially documented behaviour doesn't work.
Fortunately, it's all incredibly moot, since the real fix (in #1015) is
just about ready to go. It was being looked at again as a result of Gary
closing the ticket with a pointer to the real fix the first time, before
this thread started. So the issue wil lbe resolved in a satisfactory way
shortly anyway.
Regards,
Malcolm
jedie
the job for trac.
But on the other side: The documentation should IMHO never have
example code that doesn't work.
In this specific instance, a remark would have been enough. e.g.:
"This example code doesn't work until #1015 is fixed. A work-a-round
is to use this code: FooBar..."
Aidas Bendoraitis
never show non-working examples.
Aidas Bendoraitis aka Archatas
jedie
wrote:
> Fortunately,it'sallincrediblymoot, since the real fix (in #1015) is
> just about ready to go.Itwas being looked at again as a result of Gary
> closing the ticket with a pointer to the real fix the first time, before
> this thread started. So the issue wil lbe resolved in a satisfactory way
> shortly anyway.
"shortly"... But my "change docu" ticket is opened 2 weeks ago:
http://code.djangoproject.com/ticket/4649
The real bug is 2 years old and last modified 2 weeks ago, too:
http://code.djangoproject.com/ticket/1015
The documentation has not been changed and still display a not working
example code:
http://www.djangoproject.com/documentation/cache/#the-per-view-cache
When is "shortly" ?
Btw. In between I used the per-view-cache no more. I think only of new
users and i think it's a general question.
=;-)
voting for change the docu:
+1 - Jens Diemer
+1 - Smiley Chris
+1 - Aidas Bendoraitis
-1 - Gary Wilson
-1 - Malcolm Tredinnick
Is this right?
Malcolm Tredinnick
> On 23 Jun., 12:40, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
> > Fortunately,it'sallincrediblymoot, since the real fix (in #1015) is
> > just about ready to go.Itwas being looked at again as a result of Gary
> > closing the ticket with a pointer to the real fix the first time, before
> > this thread started. So the issue wil lbe resolved in a satisfactory way
> > shortly anyway.
>
> "shortly"... But my "change docu" ticket is opened 2 weeks ago:
> http://code.djangoproject.com/ticket/4649
>
> The real bug is 2 years old and last modified 2 weeks ago, too:
> http://code.djangoproject.com/ticket/1015
Posts like this really encourage people to stop and help you, too.
Have a look at what we've indicated is the correct fix for the problem
(#1015). Notice how the last comment on that ticket indicates what needs
to be done to get it finished? Directing your energies in that direction
would be a more productive use of time than posts like this.
Regards,
Malcolm
--
Save the whales. Collect the whole set.
http://www.pointy-stick.com/blog/
jedie
Sorry, you have misunderstood this. Thus I have not meant this. ;)
Fixing the ticket #1015 is not important to me.
The documentation philosophy is relevant for me: The documentation
should really never show non-working examples. This is the point i
mean and that is the question here.
Malcolm Tredinnick
Unsurprisingly, we are in 100% agreement. So if the documentation and
the code are in disagreement, one of them has to be fixed. Fixing the
code is the right thing in this case.
Regards,
Malcolm
--
Everything is _not_ based on faith... take my word for it.
http://www.pointy-stick.com/blog/
Nis Jørgensen
Nis
Nicola Larosa
> Sorry, you have misunderstood this. Thus I have not meant this. ;)
>
> Fixing the ticket #1015 is not important to me.
Insisting on telling people what to do, and not really doing anything
yourself, is obnoxious.
Please make a patch first, and then quibble, preferably in the ticket.
--
I accuse you, Mr. Bush, [...] of fomenting fear among your own people,
of creating the very terror you claim to have fought.
-- Keith Olbermann, July 2007
Malcolm Tredinnick
> jedie wrote:
> > Sorry, you have misunderstood this. Thus I have not meant this. ;)
> >
> > Fixing the ticket #1015 is not important to me.
>
> Insisting on telling people what to do, and not really doing anything
> yourself, is obnoxious.
>
> Please make a patch first, and then quibble, preferably in the ticket.
This is all getting a bit unnecessarily heated (I'm far from innocent
here, too, since I've let off steam in this thread).
In an effort to restore order to the Force, I'm working on this right
this minute. Hopefully that will make everybody happier and we can move
onto having fun again.
Thanks,
Malcolm
--
On the other hand, you have different fingers.
http://www.pointy-stick.com/blog/
jedie
> On Thu, 2007-07-05 at 00:39 -0700, jedie wrote:
> > The documentation philosophy is relevant for me: The documentation
> > should really never show non-working examples.
>
> the code are in disagreement, one of them has to be fixed. Fixing the
> code is the right thing in this case.
No, i thing we are not 100% agreement ;)
I think:
1. The documentation should be changed, if there is a not working code
example. (At least a node sould be inserted.)
2. Fix the bug and commit the pach.
3. Update the documentation again. (remove the obsolete note)
You think: inset a note in the documentation is needless, because the
bugfix patch would be shortly commit.
IMHO: Bugs lived a long time in django, often :(
It is not necessary to search non working example code every day or
so. But if a user find a buggy example code and write a ticked like
http://code.djangoproject.com/ticket/4649 , the documentation should
be updated until the bug is not fixed.
Tai Lee
also not provide non-working examples. therefore either the bug should
be fixed immediately, or the example should be removed immediately (to
be re-instated when the bug is fixed). it is true that many bugs
remain in trunk for a long time, either at design decision needed or
even accepted.
if there are fairly substantial long-standing bugs that get a lot of
questions and many people spend time debugging over and over again,
could there be a "known issues" page (referring back to the tickets)
that people can check first? or is this also a wasted effort, and
people should just search the tickets directly?