Re: Feature request : Load signals automatically

If you make signals autoload, you obscure what is happening. In the case of models and apps, they are so essential and tightly coupled to the framework itself that we can eschew the boilerplate for linking them together. The developer experience is almost universally better as a result. I don't

Re: Feature request : Load signals automatically

Adam points out in his reply on the forum, Django autoloads models, admins, and apps. Most Django users and maintainers love models and admins; hopefully they admit that apps solve a problem that needed solving. At the same time, many of them are also skeptical of signals, having witness

Re: Feature request : Load signals automatically

I've replied on the forum. On Tue, 14 Sept 2021 at 13:21, Roxane Bellot wrote: > > > Hi guys ! > > First of all, i’m new here, so if this issue has already been discussed or > if here is not the place to talk about it (I also opened a forum post > <https://forum.djangopr

Fwd: Feature request : Load signals automatically

Hi guys ! First of all, i’m new here, so if this issue has already been discussed or if here is not the place to talk about it (I also opened a forum post <https://forum.djangoproject.com/t/load-signals-automatically/9666>) please don’t hesitate to tell me. Also, please be aware English is

Re: docs request: signals documentation warning

r Canassa: > > > Dispatching a signal to a handler is an implicit function call. > > > > I think that's a good one to include as well, some people get the > > impression that the signals are an async Celery-like process. > > definitely. That's completely new to me e.g.

Re: docs request: signals documentation warning

Am 22.09.19 um 20:53 schrieb Cesar Canassa: > > Dispatching a signal to a handler is an implicit function call. > > I think that's a good one to include as well, some people get the > impression that the signals are an async Celery-like process. definitely. That's completely n

Re: docs request: signals documentation warning

> Dispatching a signal to a handler is an implicit function call. I think that's a good one to include as well, some people get the impression that the signals are an async Celery-like process. Best regards, Cesar On Sun, Sep 22, 2019 at 9:19 AM Aymeric Augustin < aymeric

Re: docs request: signals documentation warning

Hello, Yes, I think the docs should be a better job at preventing people from getting signal-happy without grasping all the consequences. I've faced that issue in a big (> 1 million LoC) project as well. Without getting too emotional, I think the docs could say that: 1. Sign

Re: docs request: signals documentation warning

Hi Cesar, I think the community consensus is exactly where you're at: signals are only useful in limited cases. We've even resisted adding more signals to Django core in recent years. Although the Django documentation tends to be quite neutral I think a single paragraph listing the pros and cons

docs request: signals documentation warning

Hello, I would like to propose a small change to the Django signals documentation: https://docs.djangoproject.com/en/2.2/topics/signals/ According to the documentation: > Django includes a “signal dispatcher” which helps allow decoupled applications get notified when actions occur elsewh

Re: Signals - Need a signal after annotations are added

019 at 12:08:43 PM UTC-8, Mike Brown wrote: >> >> I have a situation where I need a signal for when a model object is fully >> instantiated. >> >> Currently, there are signals for pre_init and post_init. However, when >> post_init is fired, >> the object is no

Re: Signals - Need a signal after annotations are added

ly > instantiated. > > Currently, there are signals for pre_init and post_init. However, when > post_init is fired, > the object is not fully 'initialized' in the sense that annotations have > not yet been added to the object. > > > In django.db.models.qu

Re: Signals - Need a signal after annotations are added

On Sat, Feb 23, 2019 at 9:48 PM Philip James wrote: > Hi! I think I'm misunderstanding what you're asking for. I've looked at > every doc I can find on annotations to refresh my memory, and it looks like > annotations only apply to query sets, not to objects? Could you say a bit > more about

Re: Signals - Need a signal after annotations are added

PJJ http://philipjohnjames.com On Sat, Feb 23, 2019 at 12:08 PM Mike Brown wrote: > I have a situation where I need a signal for when a model object is fully > instantiated. > > Currently, there are signals for pre_init and post_init. However, when > post_init is fired, > the o

Signals - Need a signal after annotations are added

I have a situation where I need a signal for when a model object is fully instantiated. Currently, there are signals for pre_init and post_init. However, when post_init is fired, the object is not fully 'initialized' in the sense that annotations have not yet been added to the object

Re: Updating date field using signals

This mailing list is for the development of the Django Framework. Questions related to its usage should be posted to the django-users mailing list. Regards, Michael Manfre On Fri, Nov 9, 2018 at 6:51 AM wrote: > Hi all, > > I have a very simple Profile class: > > class Profile(models.Model): >

Updating date field using signals

Hi all, I have a very simple Profile class: class Profile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE) location = models.CharField(max_length=30, blank=True) birth_date = models.DateTimeField(null=True, blank=True) date_activation =

Re: Adding signals to bulk update/create operations

use cases, > but in cases where concurrency is an issue, you'd get some loud failures, > and worse, you could get cases where things work silently wrong (one item > removed, one added concurrently). These cases would be near-impossible to > debug. > > The reason why we don't h

Re: Feature idea: forms signals

Hi JP, That's a good point, sorry I didn't make it clear. The fork is installed from within the requirements file but you can also see it here, on the ticket_27923 branch: https://github.com/seddonym/django/tree/ticket_27923 I've updated the README to help. I'd be interested to hear if

Re: Feature idea: forms signals

Hello David, Is it possible to try to use it as part of the Django fork you mention, instead of the app ? I couldn't find any link on your github profile, your website and google but perhaps I've missed it. Thanks ! Best <3 -- You received this message because you are subscribed to the

Re: Adding signals to bulk update/create operations

et cases where things work silently wrong (one item removed, one added concurrently). These cases would be near-impossible to debug. The reason why we don't have update signals is that it's hard to find a solution that allows users to run actions when an instance is updated, works correctly i

Re: Adding signals to bulk update/create operations

; .select_for_update() applied >3) fire pre_update, give the primary key set as argument >4) do the update against a queryset with .filter(pk__in=pk_set) >5) fire post_update with primary key set as argument > > This way the pre and post update signals will execute agai

Re: Adding signals to bulk update/create operations

set as argument This way the pre and post update signals will execute against a fixed set of instances. The bad part is that this can significantly slow down the .update() call, but to get actually safe signals, I don't see a way around that. - Anssi On Friday, March 31, 2017 at 3:51:34 AM

Re: Adding signals to bulk update/create operations

There's an accepted ticket about adding pre_update and post_update signals: https://code.djangoproject.com/ticket/21461. From a quick glance, I think this is what you're proposing. On Thursday, March 30, 2017 at 4:28:00 PM UTC-4, Todor Velichkov wrote: > > Consider the following piece o

Adding signals to bulk update/create operations

Consider the following piece of code: @receiver(pre_save, sender=MyModel) def my_handler(sender, **kwargs): instance = kwargs['instance'] if instance.verified: do_something(instance) else: do_else(instance) Its good, because it keeps `MyModel` decoupled from

Re: Feature idea: forms signals

I've put together a brief proof of concept here: https://github.com/seddonym/formsignals It demonstrates what you could do with post_init, post_clean and post_save signals, which I've also implemented in a fork of Django (no test coverage or documentation yet though). The concept

Re: Feature idea: forms signals

o absolutely more consensus, especially (to minimize the work for you), > please do not just suggest the signals but also their signatures and also > outline usecases for each of them. Once you outline the signatures it will be > easier for others to understand what you can do with them et

Re: Feature idea: forms signals

On Friday, March 10, 2017 at 10:12:54 AM UTC+1, David Seddon wrote: > > What are the next steps? Shall I create a pull request, or does this need > more consensus first? > Imo absolutely more consensus, especially (to minimize the work for you), please do not just suggest the sign

Re: Feature idea: forms signals

example might be to add > > > > an extra field to a login form provided by a third party module. > > > > > > > > What I end up doing is often overriding the urlconf, view and form > > > > class. Or, worse, monkey patching the form class.

Re: Feature idea: forms signals

e to add > > an extra field to a login form provided by a third party module. > > > > What I end up doing is often overriding the urlconf, view and form > > class. Or, worse, monkey patching the form class. > > > > A much nicer way to do this would be to add a fe

Re: Feature idea: forms signals

; What I end up doing is often overriding the urlconf, view and form > class. Or, worse, monkey patching the form class. > > A much nicer way to do this would be to add a few well chosen signals > to forms. > > Potential ones could be: > > - post_init Putting in a +1

Re: Feature idea: forms signals

using happily for at least a decade but I take your point as well. About OVERLOADED_CLASSES, I don't think it's flexible enough, ie. to allow an AppConfig to override a field of another app's form class, that was made possible by David's initial proposal using signals. If we're going to change

Re: Feature idea: forms signals

Hi David, It's good to hear that you did significant research in this area (which I couldn't tell from your original email). I get how this feature can come in handy and I won't stand in the way if it gets implemented. Improving the guidance about when (not) to use signals in the process

Re: Feature idea: forms signals

I totally agree that signals are open to misuse, and I take your points. Inexperienced developers often seem to use them just because they're there, rather than to encapsulate their apps and avoid circular dependencies. The Django signals documentation could probably do with a bit more

Re: Feature idea: forms signals

Hello, My experience with Django — and not just with inexperienced developers — is that signals are a footgun. I've seen them misused as workarounds for badly structured code and unclear dependency trees too often. I'm not eager to encourage their use. Fundamentally, signals in Django allow

Feature idea: forms signals

. Or, worse, monkey patching the form class. A much nicer way to do this would be to add a few well chosen signals to forms. Potential ones could be: - post_init - post_clean - post_save (for ModelForms) I'd be happy to do a pull request for this, but just wondered what people think. David -- You

Re: Added signals that runs when adding an object to a Many-To-One relation

That is correct, yes. Den måndag 6 februari 2017 kl. 21:51:52 UTC+1 skrev Tim Graham: > > I was unclear. My point is that by listening to a Manager.add() signal, > your cache invalidation handler won't catch cases where other code calls > QuerySet.update(). If update signals were

Re: Added signals that runs when adding an object to a Many-To-One relation

I was unclear. My point is that by listening to a Manager.add() signal, your cache invalidation handler won't catch cases where other code calls QuerySet.update(). If update signals were implemented and your code listened to that, there would be no need to add or listen to a Manager.add

Re: Added signals that runs when adding an object to a Many-To-One relation

Yes, my PR does just that, it sends the signal when bulk=True i.e. when an QuerySet.update() will be used. And a more general update() signal I guess would have to look through the fields that it's updating and check if its a foreign key and then send the signals for those elements some how

Re: Added signals that runs when adding an object to a Many-To-One relation

model B. This could easily be done if I had signals > for these events. And the only thing that I need to know is what instance > of B that was updated (The query is only done on objects of A but they are > all related to the same instance of B). > > If the QuerySet.update were

Re: Added signals that runs when adding an object to a Many-To-One relation

My specific need for this at the moment is that i need to do some computation (including cache invalidation) whenever objects of model A are added to/deleted from model B. This could easily be done if I had signals for these events. And the only thing that I need to know is what instance of B

Re: Added signals that runs when adding an object to a Many-To-One relation

to add signals that will be redundant if QuerySet.update() signals are added. On the other hand, if you can argue that those can't be added, then maybe we could consider this. On Monday, February 6, 2017 at 5:59:45 AM UTC-5, Oskar Persson wrote: > > And we could also maybe add signals s

Re: Added signals that runs when adding an object to a Many-To-One relation

And we could also maybe add signals similar to pre_add and post_add that are sent when calling remove() and clear() on a relation set, getting a bit closer to QuerySet.update() Den måndag 6 februari 2017 kl. 10:22:27 UTC+1 skrev Oskar Persson: > > No, if the QuerySet.update() signal

Re: Added signals that runs when adding an object to a Many-To-One relation

No, if the QuerySet.update() signals were to be implemented then these signals wouldn't be needed anymore. However, since there currently aren't any solutions for the QuerySet.update() signals that aren't a performance concern then the add signals could be a first step there. They don't solve

Re: Added signals that runs when adding an object to a Many-To-One relation

Since you created a ticket [0], I assume you feel there is value is adding this signal even if the QuerySet.update() signal is added? Could you explain the rationale? What are the performance implications of additional (possibly redundant) signals? As Aymeric said on the pull request

Re: Added signals that runs when adding an object to a Many-To-One relation

It would. Though that seems like its trying to solve a bigger issue since then you probably *need* the updated objects, which I'm not including Den fredag 3 februari 2017 kl. 18:21:55 UTC+1 skrev Tim Graham: > > #21461 proposes to add signals for QuerySet.update(). Would this solve >

Re: Added signals that runs when adding an object to a Many-To-One relation

#21461 proposes to add signals for QuerySet.update(). Would this solve your use case? https://code.djangoproject.com/ticket/21461 On Friday, February 3, 2017 at 12:14:23 PM UTC-5, mtnpaul wrote: > > Good to know. > > Thanks, > > Paul > > > On Fri, Feb 3, 2017 at 10:

Re: Added signals that runs when adding an object to a Many-To-One relation

t;> >> >> Paul >> >> On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson <oskar@polken.se> >> wrote: >> >>> Hi everyone. >>> >>> I've created a pull request (8018) >>> <https://github.com/django/django/pull/8018> tha

Re: Added signals that runs when adding an object to a Many-To-One relation

>> >> I've created a pull request (8018) >> <https://github.com/django/django/pull/8018> that adds the signals >> pre_add and post_add that are triggered when adding an object to a >> Many-To-One relation. The reason for this PR is to provide a simple (is >> ther

Re: Added signals that runs when adding an object to a Many-To-One relation

t; I've created a pull request (8018) > <https://github.com/django/django/pull/8018> that adds the signals > pre_add and post_add that are triggered when adding an object to a > Many-To-One relation. The reason for this PR is to provide a simple (is > there any other?) way to run custo

Added signals that runs when adding an object to a Many-To-One relation

Hi everyone. I've created a pull request (8018) <https://github.com/django/django/pull/8018> that adds the signals pre_add and post_add that are triggered when adding an object to a Many-To-One relation. The reason for this PR is to provide a simple (is there any other?) way to run

Re: user_login_failed and user_logged_in signals sent at different levels

The Django API is powering a single-page app, so while there are tokens instead of sessions, from the user point of view there is an explicit login process to grab a signed token. I wanted to hook to the corresponding signal to log these login events. It's probably better if I do it inside my

Re: user_login_failed and user_logged_in signals sent at different levels

Are you sure you need to depend on users "logging in" through an API? Most authentication methods used in APIs are stateless and there is no explicit login and logout process. You either include the credentials (be it bearer token, auth header, custom data or whatever) or not. The credentials

Re: user_login_failed and user_logged_in signals sent at different levels

e directly without going through >> login, perhaps it would be best to move the user_login_failed to `login` >> and let custom backends implement both signals manually if they need them. >> > > `login` unconditionally logs a user in, there is no room for failure >

Re: user_login_failed and user_logged_in signals sent at different levels

On Thursday, January 12, 2017 at 11:16:01 PM UTC+1, Federico Bond wrote: > > Since backends may call authenticate directly without going through login, > perhaps it would be best to move the user_login_failed to `login` and let > custom backends implement both signals manually

user_login_failed and user_logged_in signals sent at different levels

would expect to be able to connect to either both signals or none. Since backends may call authenticate directly without going through login, perhaps it would be best to move the user_login_failed to `login` and let custom backends implement both signals manually if they need them. What do you

Re: Test assertions for signals

ut makes it possible to make assertions about multiple signals. I think this is a better API than a totally separate assertion (we're still asserting that a signal was sent; what would the multiple version be named? assertSignalSentMultiple? Ugh.) This could be an enhancement in a separate PR, though.

Re: Test assertions for signals

t's often the case that custom signals have particular arguments they want when being sent, and which receivers will depend on. Having a shortcut for saying "needs to have at least this set of arguments provided" seemed useful to me. For background, this was written to test signal se

Re: Test assertions for signals

Hello, On 3 Jan 2017, at 09:16, James Bennett wrote: > Personally I'm against trying to do this in assertSignalSent, and would argue > for a separate assertSignalSentMultiple if that use case is deemed important > enough; coming up with a unified API that cleanly

Test assertions for signals

At DUTH this year I opened a ticket to add test-case assertions checking whether (or not) a signal was sent: https://code.djangoproject.com/ticket/27447 And corresponding PR: https://github.com/django/django/pull/7508 The PR has gotten bogged down in API design discussion, so I'd like to hash

Re: Working with Django signals

Please write to django-users as this mailing list is for the development of Django itself. On Wednesday, December 30, 2015 at 5:28:22 PM UTC-5, Bernardo Garcia wrote: > > Hi Django developers community > A great greetings > > I want share with you the following question: > > I have a custom

Working with Django signals

Hi Django developers community A great greetings I want share with you the following question: I have a custom users schema in Django for work with roles or users type, creating an application named userprofile which will be or will setup my custom user model. In my settings.py I have the

Re: Testing Signals

go internals. >> >> Simply put, I have an app that has a model that's consumed by other >> "pluggable" apps. This model will send certain signals during certain >> events that the pluggable apps can consume and respond to. >> >> I'd like to test tha

Re: Testing Signals

volve Django internals. > > Simply put, I have an app that has a model that's consumed by other > "pluggable" apps. This model will send certain signals during certain > events that the pluggable apps can consume and respond to. > > I'd like to test that my model indeed sen

Testing Signals

I posted this in Django users but didn't get any reply. I hope you don't mind me asking here. I does involve Django internals. Simply put, I have an app that has a model that's consumed by other "pluggable" apps. This model will send certain signals during certain events that the

Re: Feature request: post/pre commit/rollback signals

; django-transaction-hooks is actually better for that use case than > transaction signals are, since it does the work of handling some > situations correctly (savepoints, closed connections), which in the > case of signals are left up to the signal receiver to

Re: Feature request: post/pre commit/rollback signals

e commonly-useful case (run some > code after the current transaction successfully commits, providing the code > wasn't registered during a savepoint which was later rolled back.) I think > the API provided by django-transaction-hooks is actually better for that > use case than transact

Re: Feature request: post/pre commit/rollback signals

seful case (run some > code after the current transaction successfully commits, providing the code > wasn't registered during a savepoint which was later rolled back.) I think > the API provided by django-transaction-hooks is actually better for that > use case than transaction signals

Re: Feature request: post/pre commit/rollback signals

viding the code wasn't > registered during a savepoint which was later rolled back.) I think the API > provided by django-transaction-hooks is actually better for that use case > than transaction signals are, since it does the work of handling some > situations correctly (savepoints,

Re: Feature request: post/pre commit/rollback signals

think the API provided by django-transaction-hooks is actually better for that use case than transaction signals are, since it does the work of handling some situations correctly (savepoints, closed connections), which in the case of signals are left up to the signal receiver to handle (or more

Re: Feature request: post/pre commit/rollback signals

ch is the default in Django >= 1.6. > > If you’re using transactions (i.e. ATOMIC_REQUESTS or atomic blocks), you > may encounter the problem. But then I’m positive that transaction signals > aren’t the solution. > > > I understand that signals in general are evil and register global >

Re: Feature request: post/pre commit/rollback signals

he problem. I’m saying that the problem doesn’t happen in autocommit mode, which is the default in Django >= 1.6. If you’re using transactions (i.e. ATOMIC_REQUESTS or atomic blocks), you may encounter the problem. But then I’m positive that transaction signals aren’t the solution. &g

Re: Feature request: post/pre commit/rollback signals

Hi! In my opinion, "the default case are solved with atomic block" seems to be a workaround instead of a solution. I understand that signals in general are evil and register global callbacks is not a very good solution, but I think, that a orm should give some generic facility to a

Re: Feature request: post/pre commit/rollback signals

On 10 jan 2014, at 09:19, Jesús Espino <jespi...@gmail.com> wrote: > Hi folks! > > The propose is add post and pre signals for commit and rollback actions (as > sqlalchemy orm events). This allows attach some code when a transaction is > committed or rolled back. >

Feature request: post/pre commit/rollback signals

Hi folks! The propose is add post and pre signals for commit and rollback actions (as sqlalchemy orm events). This allows attach some code when a transaction is committed or rolled back. I have some problem, such as send email only when a transaction is committed successfully, and it's can

Re: Custom Users + Signals (reusable app)

Here's a POC<https://github.com/charettes/django/compare/lazy-class-prepared>which passes all tests on Py2 SQLite. Le mardi 29 octobre 2013 23:10:39 UTC-4, charettes a écrit : > > It is possible to attach signals to `settings.AUTH_USER_MODEL` while > taking its swappable natu

Re: Custom Users + Signals (reusable app)

It is possible to attach signals to `settings.AUTH_USER_MODEL` while taking its swappable nature into account. There might be a better way but that's how I've done it for a reusable application of mine<https://github.com/charettes/django-tenancy/blob/d6d63af092439a6f66a56ff490efb1f358c02

Custom Users + Signals (reusable app)

Folks, I am to release an app as a reusable app. However, the app makes the use of post_save signals raised by the User model and there is a problem. With the limitation of a Custom User + Signals in mind, I cannot really call it a "true" reusable app, if it doesn't work for setups

Re: Docs aren't clear on purpose of signals' "providing_args"

;> >>> >>> Well, I don't know that I would call this an *error*, so I don't think >>> opening a ticket is the right thing to do. Please let me know if I'm wrong. >>> I would just like to suggest to the developers that the purpose of >>> "providi

Re: Docs aren't clear on purpose of signals' "providing_args"

f I'm wrong. >> I would just like to suggest to the developers that the purpose of >> "providing_args" be clarified in the docs: >> >> https://docs.djangoproject.com/en/dev/topics/signals/#defining-signals >> >> Do you *have* to define what the prov

Re: Docs aren't clear on purpose of signals' "providing_args"

opening a ticket is the right thing to do. Please let me know if I'm wrong. > I would just like to suggest to the developers that the purpose of > "providing_args" be clarified in the docs: > > https://docs.djangoproject.com/en/dev/topics/signals/#defining-signals >

Docs aren't clear on purpose of signals' "providing_args"

est to the developers that the purpose of "providing_args" be clarified in the docs: https://docs.djangoproject.com/en/dev/topics/signals/#defining-signals Do you *have* to define what the providing arguments are? In my quick tests, the answer to that appears to be "no". Als

Re: #18094: signals, model inheritance, and proxy models

gt; > I haven't tried to address performance yet, but I've read all > ofhttps://code.djangoproject.com/ticket/16679and think it's possible to > keep sane overhead. There is one two really important signals for performance: pre_init and post_init. If these are fast (maybe by special cas

Re: #18094: signals, model inheritance, and proxy models

mance yet, but I've read all of https://code.djangoproject.com/ticket/16679 and think it's possible to keep sane overhead. > Another problem is that delete fires the same signal multiple times in > the inheritance chain. We can't remove the parent signal for backwards > compatibility reas

Re: #18094: signals, model inheritance, and proxy models

e chain. We can't remove the parent signal for backwards compatibility reasons, nor can we fire them as then inheriting listeners will see the delete signals multiple times. Maybe the parent class signal could be sent in a way that it is only visible to those listeners having None as thei

Re: #18094: signals, model inheritance, and proxy models

On Apr 12, 9:58 pm, Carl Meyer <c...@oddbird.net> 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; > tha

Re: #18094: signals, model inheritance, and proxy models

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

Re: #18094: signals, model inheritance, and proxy models

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 ha

Re: #18094: signals, model inheritance, and proxy models

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

Re: #18094: signals, model inheritance, and proxy models

On Thu, Apr 12, 2012 at 12:19 PM, Carl Meyer <c...@oddbird.net> 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_ini

Re: #18094: signals, model inheritance, and proxy models

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 stri

Re: #18094: signals, model inheritance, and proxy models

ly are addressing the same issue. #9318 is currently taking the approach I'd dismissed as "not a realistic option" of fixing the signals framework itself to be smart about sender subclasses. It may be that I dismissed that option too quickly. Carl signature.asc Description: OpenPGP digital signature

Re: #18094: signals, model inheritance, and proxy models

On Thu, Apr 12, 2012 at 11:31 AM, Carl Meyer <c...@oddbird.net> 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 par

Re: #18094: signals, model inheritance, and proxy models

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

#18094: signals, model inheritance, and proxy models

signals are sent both for the child and parent models. In contrast, when you delete a proxy model instance, the pre/post_delete signals are sent only for the proxy model class, never for the parent concrete class. This is problematic. Imagine a reusable tagging app that has a Tag model, and attaches

Re: Add signals for QuerySet bulk operations such as `delete`, `update, `bulk_create`

existing signals over would follow the normal deprecation policy. But it could be introduced for the bulk-level operations initially without breaking any compatibility. On Monday, March 26, 2012 4:00:14 AM UTC-4, Anssi Kääriäinen wrote: > > On 03/26/2012 06:34 AM, Byron Ruth wrote: > >

Re: Add signals for QuerySet bulk operations such as `delete`, `update, `bulk_create`

On 03/26/2012 06:34 AM, Byron Ruth wrote: Sure I guess you _could_ take a generic signals approach to handling all modify operations, but for each operation context is important. The state of the object(s) matters when performing operations. The `pre_save` and `post_save` signals for example

RE: Add signals for QuerySet bulk operations such as `delete`, `update, `bulk_create`

A somewhat different proposal is in ticket #17824: Add generic pre/post_modify signal. I think the generic "object modified" signals would fit your use case very well. The idea is that there would be just one signal which would be fired for any data modifying ORM operation. The

Add signals for QuerySet bulk operations such as `delete`, `update, `bulk_create`

My use case is for regenerating aggregate data cache at a table level. Simply calling a single signal after a bulk operation is complete would enable invalidating such aggregate cache. There is not a very clean alternate solution to this problem unless using database triggers which calls an

Re: What's the different between regressiontests/signals_regress and modeltests/signals?

On Thu, Sep 29, 2011 at 3:04 PM, Silver_Ghost <silvergho...@gmail.com> wrote: > `regressiontests/signals_regerss` was created in changeset 11710 and > `modeltests/signals` was created in changeset 6269.  It seems that they > perform same tests. The distinction bet

  1   2   3   >