On Jun 4, 5:58 pm, Jeremy Dunck wrote:
> On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen
> > Could we force the caller to define the wanted signal inheritance mode
> > when .connect() is called? The inherit mode must be one of True,False
> > or None. Default of None means no inheritance (as now)
On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen
wrote:
> On Apr 12, 10:27 pm, Anssi Kääriäinen wrote:
>> > So perhaps we do need the signal inheritance behavior to be opt-in when
>> > connecting the signal handler. I think I'd like to see a deprecation
>> > path so that eventually the inheritan
On Apr 12, 10:27 pm, Anssi Kääriäinen wrote:
> > So perhaps we do need the signal inheritance behavior to be opt-in when
> > connecting the signal handler. I think I'd like to see a deprecation
> > path so that eventually the inheritance behavior is the default, and you
> > have to opt out of it,
On Apr 12, 9:58 pm, Carl Meyer wrote:
> So this is an argument against firing the init signals multiple times,
> for each superclass, but it's not an argument against changing the
> signal framework to include superclass receivers, as proposed in #9318;
> that would not change the performance char
I think changing when signals fire is bound to cause breakages for some
apps, and of the worst variety because signals both deal with basic data
integrity and are relatively opaque (I.e. debugging is a pain). Even if the
current behavior isn't what we would choose given a blank slate, it can't
real
On 04/12/2012 12:43 PM, Anssi Kääriäinen wrote:
> It is important that pre/post init signals will not get more expensive
> than they currently are. Even now they can give around 100% overhead
> to model.__init__(). And this is in a case where the currently
> initialized model has no signals attache
It is important that pre/post init signals will not get more expensive
than they currently are. Even now they can give around 100% overhead
to model.__init__(). And this is in a case where the currently
initialized model has no signals attached at all - it is enough that
_some_ model in the project
On Thu, Apr 12, 2012 at 12:19 PM, Carl Meyer wrote:
> Also, it isn't really true that the model signals are strictly tied to
> database activity; they are tied to events on Python model objects. One
> of the three signals under discussion is the pre/post_init signal, which
> fires anytime a model
On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote:
> IOW, i think the existing signals are database-related and should be
> fired only for the concrete part(s). if the abstract part wants to,
> it can send custom signals.
Also, it isn't really true that the model signals are strictly tied to
d
On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote:
> in my mental model, there are three types of inheritance:
>
> concrete: two tables, deletion should fire two signals, one for the
> child record and one for the parent record.
>
> abstract: there's no parent table, deletion should fire one s
On 04/12/2012 10:52 AM, Jeremy Dunck wrote:
> On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer wrote:
>> There's a discussion ongoing on ticket #18094
>> (https://code.djangoproject.com/ticket/18094) that has enough potential
>> back-compat implications that it seems worth getting feedback here.
>
> S
On Thu, Apr 12, 2012 at 11:31 AM, Carl Meyer wrote:
> Thoughts?
in my mental model, there are three types of inheritance:
concrete: two tables, deletion should fire two signals, one for the
child record and one for the parent record.
abstract: there's no parent table, deletion should fire one s
On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer wrote:
> Hi all,
>
> There's a discussion ongoing on ticket #18094
> (https://code.djangoproject.com/ticket/18094) that has enough potential
> back-compat implications that it seems worth getting feedback here.
Small note, I'll try to respond to the who
Hi all,
There's a discussion ongoing on ticket #18094
(https://code.djangoproject.com/ticket/18094) that has enough potential
back-compat implications that it seems worth getting feedback here.
Currently, when you delete a concrete-inheritance child model instance,
pre_delete and post_delete sign
14 matches
Mail list logo
