Dear Tim & All,
thanks for the hint, it works! I filed a ticket [1] and i'm also
preparing a PR. Should i send the PR against 'master' or the
'stable/1.11.x' branch?
[1] https://code.djangoproject.com/ticket/27815#ticket
Thanks, regards
Zoltan Gyarmati
https://zgyarmati.de
On 02/06/2017 11:05
That looks like an oversight in the class-based view conversion [0].
Probably LoginView() needs a get_form_kwargs() method. Would you like to
create a ticket and provide a patch?
[0]
https://github.com/django/django/commit/78963495d0caadb77eb97ccf319ef0ba3b204fb5
On Monday, February 6, 2017 at
Dear All,
i'm developing a multi-tenant application where it would be extremely
handy to have the request object in my custom authentication backend
available, so i went ahead and started to use the /1.11a,/ version,
which already has the commit:
4b9330c Fixed #25187 -- Made request available in
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 implemented and
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() signa
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
Den
Tell me if I'm wrong because I haven't worked through things in detail but
it seems to me that an "add" signal wouldn't catch the case where objects
are added or delete using QuerySet.update(). For the update() signal to
process objects of B, it looks like you would check the 'update_fields"
kw
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 t
Could you describe your use case in more detail? I feel like it would
result in less code duplication to write signal handlers for Model.save()
and QuerySet.update() rather than for remove(), clear(), add(), and set()
(the more high level ways that an object could be updated). I'm not happy
to
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() signals were to be
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
a
11 matches
Mail list logo
