@Anssi, Perhaps we could use your approach above, except using rowids
instead of primary keys? Many SQL flavors support retrieving the rowids of
the created/updated rows within the same query as a bulk create/update
(e.g. OUTPUT or RETURNING).
Greg
On Thursday, April 6, 2017 at 12:53:55 AM UTC
On Friday, March 31, 2017 at 10:50:54 AM UTC+3, Todor Velichkov wrote:
>
> @Anssi, thank you for your response.
> I really haven't think about threat safety, but maybe its because in our
> specific usage it's close to impossible to happen.
>
> What do you think about this:
> 1) Put everything into
@Tim, sorry about that, I did a search before I posted, but it looks like
it slipped away somehow.
@Anssi, thank you for your response.
I really haven't think about threat safety, but maybe its because in our
specific usage it's close to impossible to happen.
What do you think about this:
1) Pu
The problem with passing the queryset is that it's possible that some
object is added to or removed from the queryset between the pre_update and
actual update execution. To avoid this the execution should go somewhere
along the lines of:
1) if there is pre_update or post_update do stages 2-5,
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 of code:
>
