Re: Potential bugs / need for extra documentation in 'Customizing the comments framework'
On Sat, Mar 27, 2010 at 2:31 AM, subs...@gmail.com wrote: >> > 3) Models hoping to foreignkey to whatever comments model the app >> I'm not sure what you're saying here. Are you complaining about the >> way that we've implemented this particular feature, or about some edge >> case that you've found that causes problems? >> > > This sounds to me like a misuse of sender to me. The sender is >> supposed to be a specific object that has sent the signal; a callable >> doesn't really meet that requirement. Internally, it's the id() of the >> python object that is used to key sender-based signals; I'm guessing >> in this case the sender should be the comment instance itself, not the >> callable that will produce the class that is used to produce comments. > > It many cases we are free to use the result of a callable and a > callable interchangeably [x = y(); do(x) vs do(y())]. In these cases, > we may not, which is perfectly fine--as you say, there are Internal > and important reasons. I suppose a MoronException would be preferrable > to the ambiguous results I achieved (some were so subtle I didn't > realize until it was in production for a few days). The problem is that I'm not sure what condition the MoronException would be raised. Strictly, you *can* use a callable as the sender.. It's just that the id() of a callable is subject to change, depending on where you get the reference to the sender. If you can consistently use *exactly* the same instance of a callable, you'll be fine. A related problem was reported a few weeks ago. There is some common wisdom floating around that you can use strings as a sender; however, the problem is that the string 'origin1' and the string "n=1; 'origin%s' % n " aren't actually the same string, so they won't activate the same signals if you activate based on sender. Again, this is id() related; you *can* use a string as a sender, but you have to use the *same* string - not just in content, but in id(). Ticket #13080 has been logged as a reminder to improve the documentation regarding sender; these id-based issues are the biggest area where clarification is required. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Potential bugs / need for extra documentation in 'Customizing the comments framework'
> I can't think of any reason that a production server should behave > differently to a development server on the sorts of issues you're > referring to. If there's a problem, I would be highly surprised if > it's caused by the fact you're running under wsgi, rather than the > devserver. There may be differences between your production > environment and your development environment that cause these > problems, but if you were to reverse the environmental issues, I > suspect you would find production working fine, but development > failing. And yet. I did everything I could to get the missing comments_app error to pop in dev, but I was unable to mirror the effects in dev. The two environments are already incredibly simple--one server houses little else but the project in question. > > Three things: > > 1) Its not obvious to me why, but importing a custom comment model as > > 'Comment' seems, somehow, to get back upstream to > A bug of this sort really needs a specific example. It's impossible to > tell from the detail you provide whether this is a legitimate bug, or > a flaw in your usage (and if it is a flaw in your usage, whether there > is anything we can do to better report errors). Agreed. I will munge around more and see if I can't come up with that. > > 3) Models hoping to foreignkey to whatever comments model the app > I'm not sure what you're saying here. Are you complaining about the > way that we've implemented this particular feature, or about some edge > case that you've found that causes problems? > > This sounds to me like a misuse of sender to me. The sender is > supposed to be a specific object that has sent the signal; a callable > doesn't really meet that requirement. Internally, it's the id() of the > python object that is used to key sender-based signals; I'm guessing > in this case the sender should be the comment instance itself, not the > callable that will produce the class that is used to produce comments. It many cases we are free to use the result of a callable and a callable interchangeably [x = y(); do(x) vs do(y())]. In these cases, we may not, which is perfectly fine--as you say, there are Internal and important reasons. I suppose a MoronException would be preferrable to the ambiguous results I achieved (some were so subtle I didn't realize until it was in production for a few days). -Steve -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Potential bugs / need for extra documentation in 'Customizing the comments framework'
On Thu, Mar 25, 2010 at 4:36 PM, subs...@gmail.com wrote:
> I got myself into a situation with a project and some comments models.
> Perhaps with some discussion we can uncover genuine code-bugs, but my
> knowledge about this is limited and so I'm just calling for a
> documentation update. A major reason I'm asking for some notice of
> these things to appear somewhere is that all of the below seems to
> work perfectly fine in the dev server. On deployment, its a confusing
> catastrophy that, at best, gives you a vague ImproperlyConfigured?
> ("The COMMENTS_APP setting refers to a non-existing package."), which
> is of course no help at all.
I can't think of any reason that a production server should behave
differently to a development server on the sorts of issues you're
referring to. If there's a problem, I would be highly surprised if
it's caused by the fact you're running under wsgi, rather than the
devserver. There may be differences between your production
environment and your development environment that cause these
problems, but if you were to reverse the environmental issues, I
suspect you would find production working fine, but development
failing.
> Three things:
>
> 1) Its not obvious to me why, but importing a custom comment model as
> 'Comment' seems, somehow, to get back upstream to
> django.contrib.comments and wreck things. If this is due to the nature
> of that particular frameworks' immaculate ability to be extensive and
> provide conveniences all around, so be it. I'd just like a notice next
> time before I attempt to save code by doing Comment =
> comments.get_model() and expect everything to be honkey dorey.
A bug of this sort really needs a specific example. It's impossible to
tell from the detail you provide whether this is a legitimate bug, or
a flaw in your usage (and if it is a flaw in your usage, whether there
is anything we can do to better report errors).
> 2) A custom comments app should not also be called 'comments'.
> Probably a very obvious one but the problems it creates are
> inconsistent between dev and live and not obvious.
This should clearly be caught as a validation error -- having two
applications with the same appname is bound to cause problems. I'm
actually slightly surprised that it isn't caught as a validation error
already. This isn't a documentation flaw - it's a flaw in code.
> 3) Models hoping to foreignkey to whatever comments model the app
> provides should not be passed the callable comments.get_model(). I
> realize passing callables into a ForeignKey probably seems strange in
> and of itself, however, once again it creates inconsistent problems
> between dev and live which never connect back to the FK in any obvious
> way.
I'm not sure what you're saying here. Are you complaining about the
way that we've implemented this particular feature, or about some edge
case that you've found that causes problems?
> 4) Probably a dupe of above, but passing the callable into a signal as
> sender also fails, and your signal is never respected.
This sounds to me like a misuse of sender to me. The sender is
supposed to be a specific object that has sent the signal; a callable
doesn't really meet that requirement. Internally, it's the id() of the
python object that is used to key sender-based signals; I'm guessing
in this case the sender should be the comment instance itself, not the
callable that will produce the class that is used to produce comments.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Potential bugs / need for extra documentation in 'Customizing the comments framework'
I got myself into a situation with a project and some comments models.
Perhaps with some discussion we can uncover genuine code-bugs, but my
knowledge about this is limited and so I'm just calling for a
documentation update. A major reason I'm asking for some notice of
these things to appear somewhere is that all of the below seems to
work perfectly fine in the dev server. On deployment, its a confusing
catastrophy that, at best, gives you a vague ImproperlyConfigured?
("The COMMENTS_APP setting refers to a non-existing package."), which
is of course no help at all.
Three things:
1) Its not obvious to me why, but importing a custom comment model as
'Comment' seems, somehow, to get back upstream to
django.contrib.comments and wreck things. If this is due to the nature
of that particular frameworks' immaculate ability to be extensive and
provide conveniences all around, so be it. I'd just like a notice next
time before I attempt to save code by doing Comment =
comments.get_model() and expect everything to be honkey dorey.
2) A custom comments app should not also be called 'comments'.
Probably a very obvious one but the problems it creates are
inconsistent between dev and live and not obvious.
3) Models hoping to foreignkey to whatever comments model the app
provides should not be passed the callable comments.get_model(). I
realize passing callables into a ForeignKey probably seems strange in
and of itself, however, once again it creates inconsistent problems
between dev and live which never connect back to the FK in any obvious
way.
4) Probably a dupe of above, but passing the callable into a signal as
sender also fails, and your signal is never respected.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
