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
> 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
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 bac
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 configur
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 t
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.
> 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 thi
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 thi
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/m
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 mes
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
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
> 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 issu
>
> 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 in
>
> 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
du
15 matches
Mail list logo
