custom signal fails silently, depending on import path (bug ?)

[ssc]

I use a custom signal in my Django app in signals.py:

my_project/
  my_app/
signals.py
views.py

In views.py, if I do 'from signals import my_custom_signal' and send
the signal, everything is fine. However, if I do 'from my_app.signals
import my_custom_signal' and send the signal, it never arrives at the
signal handler, no error message, nothing, just fails silently.

Has anyone ever come across this before ? Could not find anything
related in Trac, but I thought I better ask in here before I file a
bug...
-- 
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: Model validation incompatibility with existing Django idioms

[Skylar Saveland]

> ModelForm has a save() method that saves the model. It is reasonable
> to assume that if the form is valid, the save() method call should
> succeed, that's why the entire model is validated.

mf.is_valid() I have understood as validation strictly on the included
fields in the form.  I abuse this "feature".  Once I know that
something has been done validly by the user, I can bring into motion
all kinds of things.  As you can see all of these forms and their ilk
are intentionally excluding known required fields.

class MinimalContactForm(forms.ModelForm):
class Meta:
model = Contact
fields = ('first', 'm', 'last')

class PrimaryContactForm(forms.ModelForm):
class Meta:
model = Contact
exclude = ('user','primary', 'address', 'email')

class ContactForm(forms.ModelForm):
class Meta:
model = Contact
exclude = ('user',)

I know that you know what I'm saying, so let's see

> We could create a PartialModelForm, that would have save() method only
> when editing (and not adding) models and have other method (or
> enforced commit=False) for retrieval of the partial model. This form
> would only call validation on the modelfields that are part of the
> form (not being excluded). This is the behavior I understand everybody
> expects from ModelForm, so, for backwards compatibility, we could call
> it just ModelForm.

not entirely sure what you mean

> only when editing (and not adding) models and have other method (or
> enforced commit=False) for retrieval of the partial model

.

> Also please mind that it could prove difficult to do half the
> validation in one place and other fields elsewhere without a form.
> Models, as opposed to forms, don't have a state in sense of
> validated/raw and they don't track changes to their fields' data.
> That's why validation is run every time and the results are not cached
> on the instance.
>
> Few quick questions to get some ideas:
>
> 1) If editing a model (passed an instance parameter to __init__), even
> with a partial form, do you expect model.full_validate being called?
>
> 2) Are you OK with ripping save(commit=False) functionality to some
> other method? (current functionality can stay with a deprecation
> warning for example)

I wouldn't like to see that idiom changed.  We can create another attr
on the form but leave is_valid()?

> 3) Would you want errors raised in model validation after it being
> created by a form (commit=False) to appear on the form?

I suppose that I have been guilty of taking advantage of modelforms to
an extreme degree.  I don't picture needing model validation on my
modelforms right now.  I sometimes have a bunch of small forms (if the
case needs) like:

Applicant information
{{form|as_uni_form}}
{{profile_form|as_uni_form}}
How may we contact you?
{{contact_form|as_uni_form}}
How did you hear about us?
{{hear_about|as_uni_form}}
Terms and Conditions
{{tos_form|as_uni_form}}

if form.is_valid() and profile_form.is_valid()...:
... do magic to create user ...
add the required user field to the other objects with commit=False
idiom

Perhaps in this way I am also abusing the relational db.  But, I
always find occasion to add required fields (often FK to the other
modelforms) after I know the form "is
valid" (UnresolvableValidationError).

But, I would like another attr, so I could call modelform.model_errors
() or modelform.model_is_valid() or something.  Just plugging my own
self interest here though really.

I would like to see everything that I use behave exactly as I have
come to know it and then see other new features popping up around
that.

>
> on subject of inlines:
> 1) Is it acceptable to create a model and not it's inlines in the
> admin if the modelform validates but the inlines don't?
>
> 2) How can we limit people's validation code to avoid validating FKs
> in inlines since users can (and should) create their own validation
> logic on Models? Especially when we try and treat admin as "just a
> cool app" and not something people should really design for.
>
> 3) How would you feel on creating an option to enable behavior (1) )
> and document that models with side effects in their save and delete
> should really go for that?
>
> 4) Making 3) the default and enable switching it off if people want
> their admin page to save atomically.
>
> Please let me know what you think

I don't really know enough about the internals of the admin to say
much about that.
-- 
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: Model validation incompatibility with existing Django idioms

[David Cramer]

For us we definitely use this behavior, and I'm guessing this is about
to bite us in the ass. I would think a simple fix would be to have a
commit=False, and validate=True keyword arg. By default, validate is
NoInput, but if commit is False it defaults to False. Wouldn't that be
a simple enough backwards compatible workaround?

On Jan 7, 10:40 am, Honza Král  wrote:
> Hi everybody, sorry for the late reply, was busy.
>
> Just to add few points that lead us to do it this way:
>
> ModelForm has a save() method that saves the model. It is reasonable
> to assume that if the form is valid, the save() method call should
> succeed, that's why the entire model is validated.
>
> We could create a PartialModelForm, that would have save() method only
> when editing (and not adding) models and have other method (or
> enforced commit=False) for retrieval of the partial model. This form
> would only call validation on the modelfields that are part of the
> form (not being excluded). This is the behavior I understand everybody
> expects from ModelForm, so, for backwards compatibility, we could call
> it just ModelForm.
>
> Also please mind that it could prove difficult to do half the
> validation in one place and other fields elsewhere without a form.
> Models, as opposed to forms, don't have a state in sense of
> validated/raw and they don't track changes to their fields' data.
> That's why validation is run every time and the results are not cached
> on the instance.
>
> Few quick questions to get some ideas:
>
> 1) If editing a model (passed an instance parameter to __init__), even
> with a partial form, do you expect model.full_validate being called?
>
> 2) Are you OK with ripping save(commit=False) functionality to some
> other method? (current functionality can stay with a deprecation
> warning for example)
>
> 3) Would you want errors raised in model validation after it being
> created by a form (commit=False) to appear on the form?
>
> on subject of inlines:
> 1) Is it acceptable to create a model and not it's inlines in the
> admin if the modelform validates but the inlines don't?
>
> 2) How can we limit people's validation code to avoid validating FKs
> in inlines since users can (and should) create their own validation
> logic on Models? Especially when we try and treat admin as "just a
> cool app" and not something people should really design for.
>
> 3) How would you feel on creating an option to enable behavior (1) )
> and document that models with side effects in their save and delete
> should really go for that?
>
> 4) Making 3) the default and enable switching it off if people want
> their admin page to save atomically.
>
> Please let me know what you think
>
> Thanks!
>
> Honza Král
> E-Mail: honza.k...@gmail.com
> Phone:  +420 606 678585
-- 
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: Final call for feedback: Multi-db

[Russell Keith-Magee]

On Fri, Jan 8, 2010 at 3:17 AM, Brett Hoerner  wrote:
> On Jan 5, 8:09 pm, Russell Keith-Magee  wrote:
>> If you're actually doing master/slave in the wild, your guidance may
>> actually be more enlightening than my theoretical navel gazing. In
>> particular - how have you got master/slave configured? How do you find
>> and select slave databases? How does that approach degrade when
>> DATABASES suddenly has less entries (including the case of a config
>> with no slaves)?
>
> Yes, we're actually doing read-slave queries on Django 1.0.x using
> some private API hacks.
>
> We basically have the same layout of DATABASES that multidb went with,
> but we only use different managers to dispatch queries.  In other
> words, `Foo.rs_objects.all()' vs `Foo.objects.all()'.  It's pretty
> basic, but it's worked for us.
>
> So that's equivalent to the `using' syntax, you can just imagine we
> have places in our code where the developer knows that read-slave
> replication isn't a problem and we want to offload a query, so
> `Foo.objects.using('read_slave')...' is used.  We don't do any special
> selection right now, `DATABASES['read_slave']' is hard coded per
> deployment instance, different instances might use different read-
> slaves for various reasons but those reasons also require us to use
> whole different app servers too, and so those requests are chosen by a
> frontend proxy rather than some in-app magic.
>
> Anyway, most of that doesn't really matter, I think.  What matters is
> that we don't do any special degrading if `DATABASES' is different.
> As soon as you use `using' (or our equivalent) you're hard coding the
> use of another DB name, so in development we just have `DATABASES
> ['read_slave']' use the same settings as `default' does.

> So in the end the `TEST_NAME=None' solution works well for our case at
> least, I would imagine for any number of read-slaves you'd want to be
> able to point them at the `default' DB (without doing a dump and sync)
> during tests - I mean, that's what a read-slave is, no?

I completely agree that you don't need to have read slaves in order to
test application logic (unless, of course, you're checking your read
slave selection behavior).

However, I'm a little confused as to how your setup will work with the
change you propose, If you have a database setup with:

"read-slave": { ... TEST_NAME=None },

then my understanding of your proposal is that the only change is that
read-slave won't get created under the test setup. But doesn't that
mean that::

MyModel.objects.using('read-slave').filter(...)

will fall over? Either the read-slave alias won't exist in DATABASES
(if we fully clean up the DATABASES setting), or the read-slave alias
will point to a database with no name.

In your opinion, how does using() (or the test framework) compensate
for a database alias that is referenced in code, but non-existent
during testing?

FYI - I've opened #12542 to track this particular issue. I've also
opened #12541 to track the cross database validation/read slave
identification problem you raised earlier.

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: Django docs aren't aware custom model save methods need the "using" keyward arg.

[Russell Keith-Magee]

On Fri, Jan 8, 2010 at 7:17 AM, j...@jeffcroft.com  wrote:
> With MultiDB, it's now essential that custom model save methods accept
> the "using" keyword argument. However, the docs explicitly suggest a
> signature like:
>
> def save(self, force_insert=False, force_update=False):
>
> (You can see this here, for example:
> http://docs.djangoproject.com/en/dev/topics/db/models/#overriding-predefined-model-methods)
>
> I would suggest the docs ought to instruct users to use a signature
> like:
>
> def save(self, *args, **kwargs):

I've just updated the docs to say exactly that. Thanks for the suggestion.

Russ %-)
-- 
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: Django docs aren't aware custom model save methods need the "using" keyward arg.

[Alex Gaynor]

On Thu, Jan 7, 2010 at 5:25 PM, j...@jeffcroft.com  wrote:
>> Are you sending from other email addresses?  I only see a few
>> occurrences of j...@jeffcroft.com on django-dev, and I haven't seen
>> you get destroyed.  :-/  Sucks that you feel that way.
>
> The destruction tends to come via Twitter. :)
>
> I was half-joking, it's not a big deal.
>
> --
> 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.
>
>
>
>

Yep, there's a ticket for this, just an oversight when we did the docs.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
-- 
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: Django docs aren't aware custom model save methods need the "using" keyward arg.

[j...@jeffcroft.com]

> Are you sending from other email addresses?  I only see a few
> occurrences of j...@jeffcroft.com on django-dev, and I haven't seen
> you get destroyed.  :-/  Sucks that you feel that way.

The destruction tends to come via Twitter. :)

I was half-joking, it's not a big deal.
-- 
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: Django docs aren't aware custom model save methods need the "using" keyward arg.

[Jeremy Dunck]

On Thu, Jan 7, 2010 at 5:17 PM, j...@jeffcroft.com  wrote:
...
> I would suggest the docs ought to instruct users to use a signature
> like:
>
> def save(self, *args, **kwargs):

Sounds reasonable to me.

> I will now duck and cover, as I tend to get destroyed anytime i say
> anything at all in this group.

Are you sending from other email addresses?  I only see a few
occurrences of j...@jeffcroft.com on django-dev, and I haven't seen
you get destroyed.  :-/  Sucks that you feel that way.
-- 
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.

Django docs aren't aware custom model save methods need the "using" keyward arg.

[j...@jeffcroft.com]

With MultiDB, it's now essential that custom model save methods accept
the "using" keyword argument. However, the docs explicitly suggest a
signature like:

def save(self, force_insert=False, force_update=False):

(You can see this here, for example:
http://docs.djangoproject.com/en/dev/topics/db/models/#overriding-predefined-model-methods)

I would suggest the docs ought to instruct users to use a signature
like:

def save(self, *args, **kwargs):

I will now duck and cover, as I tend to get destroyed anytime i say
anything at all in this group.

Jeff
-- 
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: Message level API awkwardness

[SmileyChris]

On Jan 6, 11:09 pm, Jeremy Dunck  wrote:
> I realize I'm very late giving feedback on the API, sorry and feel
> free to ignore if I'm too late.
>
> That said, from the docs, the API to set the effective messaging level
> is awkward:
>
> ==
> # Change the messages level to ensure the debug message is added.
> messages.get_messages(request).level = messages.DEBUG
> ==
>
> To *set* the messaging level, I call .get_messages?
>
> I think I understand the reason this was done-- get_messages is
> backend- and request-specific, but it is definitely surprising.
>
> Perhaps something like this would do better?
>
> messages.effective_level(request) => messages.INFO
> messages.set_effective_level(request, messages.DEBUG)
> ?
>
Yes, that sounds good. I also like Tobias' names better
-- 
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: Final call for feedback: Multi-db

[Brett Hoerner]

On Jan 5, 8:09 pm, Russell Keith-Magee  wrote:
> If you're actually doing master/slave in the wild, your guidance may
> actually be more enlightening than my theoretical navel gazing. In
> particular - how have you got master/slave configured? How do you find
> and select slave databases? How does that approach degrade when
> DATABASES suddenly has less entries (including the case of a config
> with no slaves)?

Yes, we're actually doing read-slave queries on Django 1.0.x using
some private API hacks.

We basically have the same layout of DATABASES that multidb went with,
but we only use different managers to dispatch queries.  In other
words, `Foo.rs_objects.all()' vs `Foo.objects.all()'.  It's pretty
basic, but it's worked for us.

So that's equivalent to the `using' syntax, you can just imagine we
have places in our code where the developer knows that read-slave
replication isn't a problem and we want to offload a query, so
`Foo.objects.using('read_slave')...' is used.  We don't do any special
selection right now, `DATABASES['read_slave']' is hard coded per
deployment instance, different instances might use different read-
slaves for various reasons but those reasons also require us to use
whole different app servers too, and so those requests are chosen by a
frontend proxy rather than some in-app magic.

Anyway, most of that doesn't really matter, I think.  What matters is
that we don't do any special degrading if `DATABASES' is different.
As soon as you use `using' (or our equivalent) you're hard coding the
use of another DB name, so in development we just have `DATABASES
['read_slave']' use the same settings as `default' does.

So in the end the `TEST_NAME=None' solution works well for our case at
least, I would imagine for any number of read-slaves you'd want to be
able to point them at the `default' DB (without doing a dump and sync)
during tests - I mean, that's what a read-slave is, no?

Regards,
Brett
-- 
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: Model validation incompatibility with existing Django idioms

[Honza Král]

Hi everybody, sorry for the late reply, was busy.


Just to add few points that lead us to do it this way:

ModelForm has a save() method that saves the model. It is reasonable
to assume that if the form is valid, the save() method call should
succeed, that's why the entire model is validated.

We could create a PartialModelForm, that would have save() method only
when editing (and not adding) models and have other method (or
enforced commit=False) for retrieval of the partial model. This form
would only call validation on the modelfields that are part of the
form (not being excluded). This is the behavior I understand everybody
expects from ModelForm, so, for backwards compatibility, we could call
it just ModelForm.

Also please mind that it could prove difficult to do half the
validation in one place and other fields elsewhere without a form.
Models, as opposed to forms, don't have a state in sense of
validated/raw and they don't track changes to their fields' data.
That's why validation is run every time and the results are not cached
on the instance.


Few quick questions to get some ideas:

1) If editing a model (passed an instance parameter to __init__), even
with a partial form, do you expect model.full_validate being called?

2) Are you OK with ripping save(commit=False) functionality to some
other method? (current functionality can stay with a deprecation
warning for example)

3) Would you want errors raised in model validation after it being
created by a form (commit=False) to appear on the form?

on subject of inlines:
1) Is it acceptable to create a model and not it's inlines in the
admin if the modelform validates but the inlines don't?

2) How can we limit people's validation code to avoid validating FKs
in inlines since users can (and should) create their own validation
logic on Models? Especially when we try and treat admin as "just a
cool app" and not something people should really design for.

3) How would you feel on creating an option to enable behavior (1) )
and document that models with side effects in their save and delete
should really go for that?

4) Making 3) the default and enable switching it off if people want
their admin page to save atomically.


Please let me know what you think

Thanks!


Honza Král
E-Mail: honza.k...@gmail.com
Phone:  +420 606 678585
-- 
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: Using Django with Jinja2 and TEMPLATE_DEBUG=True

[Michael Elsdörfer]

> No, it wouldn't (at least, not completely). Jinja wouldn't extend
> Django's TemplateSyntaxError class, so using the approach you
> describe, Jinja's TemplateSyntaxErrors wouldn't break the debug page,
> but you wouldn't get good template error feedback either.

FWIW, I don't think that's an issue; Jinja 2 has it's own debug mode
it which it rewrites an exception's stack trace with line numbers from
the raw template, so I don't think TEMPLATE_DEBUG would give any
additional benefit anyway.

Michael
-- 
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: user_passes_test decorator changes in 1.2

[Gary Reynolds]

>
> Yes, that definitely falls into the category of relying on an
> implementation detail, rather than something that should be mentioned
> as a backwards incompatibility.  At the level of inspecting code
> objects (which is essentially what your code was doing), almost any
> change is backwards incompatible.  'view_func' is not only not
> documented, it is a member of a class which is private and marked as
> such - _CheckLogin.
>

Yeah, I expected that. At the time I wrote it (a while back now) I was a bit
worried it could/should have been done better by me; lesson learned.

Personally, I'd use this as an opportunity to find a more robust way
> of getting that information to the template tag :-)
>

Fair call! I'll plug away at that and if I have any more questions I'll move
my questioning over to django-users.

Thanks,
Gary
-- 

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: Problem with history view in admin page

[Mario Briggs]

>
> I'm not sure what you're asking me. "Blockers" of what?
>

I meant, for sure we know that the backend can switch the lookup to
the hidden column (from the original column) by overriding -
'field_cast_sql(self, db_type):'

The backend also needs to execute the SQL to create the hidden column
during Django's index creation process. Rahul hasnt yet started
digging where to add that. The 'Blocker' question was if uphead anyone
knew that would be problematic for the backend to do ?

regards
Mario
-- 
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.