date:20181211

Re: [Django] #30022: Doc how to combine post_save signal with on_commit to alter a m2m relation when saving a model instance

2018-12-11 Thread Django

#30022: Doc how to combine post_save signal with on_commit to alter a m2m 
relation
when saving a model instance
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Hello George,

 This is getting in into django-user territory but the `test_user` test
 happens to fail if you remove the `on_transaction_commit` decorator on the
 `post_save` receiver because of
 [https://docs.djangoproject.com/en/2.1/topics/forms/modelforms/#the-save-
 method how model forms m2m saving works].

 `ModelForm.save()` start by saving their attached instance, which triggers
 `post_save` signals, and then save their m2m values. In your case since
 `superuser_data` doesn't include any value for `groups` then the following
 chain of actions happen on `change_form.save()` if you remove the
 `on_transaction_commit` decorator.

 1. `user` get assigned `superuser_data` and its `save()` method is
 invoked.
 2. The `post_save` signal is fired and the group gets added.
 3. The form saves the `groups` m2m to an empty set because `groups` is
 missing from `superuser_data`.

 You can confirm this is the case by changing your `test_user` test to the
 following.

 {{{#!python
 def test_user(group, user_data, superuser_data):
 '''
 This test will fail if on_commit is not used in the signal.
 '''
 creation_form = UserCreationForm(data=user_data)
 user = creation_form.save()
 change_form = UserChangeForm(instance=user, data=superuser_data)
 assert change_form.is_valid()
 with transaction.atomic():
 superuser = change_form.save(commit=False)
 superuser.save()
 assert group in superuser.groups.all()
 superuser.save_m2m()
 assert group not in superuser.groups.all()
 }}}

 When your `post_save` receiver is decorated with `on_transaction_commit`
 the group addition happens to be performed ''after'' `save_m2m` is called
 which happens to make the test pass.

 What you should do to assert `user.is_superuser ==
 user.groups.filter(name='superusers').exists()` consistency is hook into
 the `m2m_changed` signal as well instead of relying on unrelated
 `on_commit` behaviour. For example,

 {{{#!python
 @receiver(
 m2m_changed,
 sender=User.groups.through
 )
 def ensure_groups_consistency(signal, sender, instance, action, pk_set,
 **kwargs):
 if instance.is_superuser and action in ('pre_remove', 'post_clear'):
 group = Group.objects.get(name='Superusers')
 if action == 'pre_remove' and group.pk in pk_set:
 pk_set.remove(group.pk)
 elif action == 'post_clear':
 instance.groups.add(group)
 }}}

 As I said earlier this is probably better discussed on support channels
 that here as this is expected behaviour.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ee19edd35212e10c5491c2c33fe4d5b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29928: TestCase doesn't check for foreign key constraints when using sqlite

2018-12-11 Thread Django

#29928: TestCase doesn't check for foreign key constraints when using sqlite
-+-
 Reporter:  Michel Samia |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite db foreign| Triage Stage:  Accepted
  key TestCase   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I had to implement fast constraint checking on SQLite when working on
 #30033 to avoid slowing down migrations and it looks like once it lands it
 could be as easy as turning `can_defer_constraint_checks`. The new check
 is fast enough to not be noticeable at all on SQLite 3.20+ at least.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.f9f5ede35cac4443a1fa19e55b88e3da%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29981: "Please correct the error below." (with no errors displayed) when changing an inline that has a one-to-one relation to the parent that uses to_field

2018-12-11 Thread Django

#29981: "Please correct the error below." (with no errors displayed) when 
changing
an inline that has a one-to-one relation to the parent that uses to_field
---+-
 Reporter:  Bernie |Owner:  Patrik Sletmo
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Patrik Sletmo):

 * has_patch:  0 => 1


Comment:

 It has been a busy week so I haven't really been able to spend any time on
 this until now. I have submitted a patch with a fix for the issue together
 with a regression test.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.21b14f015fcdc270675adceb1a62888b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30032: Can't alter the default of a DateTimeField to be TransactionNow

2018-12-11 Thread Django

#30032: Can't alter the default of a DateTimeField to be TransactionNow
-+-
 Reporter:  Gavin Wahl   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Datebase level defaults are not supported yet, see #470.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8df76a47c111e1e6c4bfb2d1d6fe15c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30033: SQLite schema editor should use the documented to emulate table alterations on SQlite3.

2018-12-11 Thread Django

#30033: SQLite schema editor should use the documented to emulate table 
alterations
on SQlite3.
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Simon Charette:

Old description:

> In the light of #29182 SQLite's main author mentioned that we should
> conform to the documented procedure to emulate table alterations on
> SQlite3.
>
> Right now the [https://www.sqlite.org/lang_altertable.html#caution
> SQLite's schema editor follows a procedure documented as incorrect] and
> prevents usages of the SQLite 3.26 improvements regarding table and
> column renames while foreign key constraints are disabled.

New description:

 In the light of #29182
 [https://github.com/django/django/pull/10733#issuecomment-445862681
 SQLite's main author mentioned] that we should conform to the documented
 procedure to emulate table alterations on SQlite3.

 Right now the [https://www.sqlite.org/lang_altertable.html#caution
 SQLite's schema editor follows a procedure documented as incorrect] and
 prevents usages of the SQLite 3.26 improvements regarding table and column
 renames while foreign key constraints are disabled.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c61c1bfe1ec61f68b7894c38553cb7c1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30033: SQLite schema editor should use the documented to emulate table alterations on SQlite3.

2018-12-11 Thread Django

#30033: SQLite schema editor should use the documented to emulate table 
alterations
on SQlite3.
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * has_patch:  0 => 1


Old description:

> In the light of #29182
> [https://github.com/django/django/pull/10733#issuecomment-445862681
> SQLite's main author mentioned] that we should conform to the documented
> procedure to emulate table alterations on SQlite3.
>
> Right now the [https://www.sqlite.org/lang_altertable.html#caution
> SQLite's schema editor follows a procedure documented as incorrect] and
> prevents usages of the SQLite 3.26 improvements regarding table and
> column renames while foreign key constraints are disabled.

New description:

 In the light of #29182
 [https://github.com/django/django/pull/10733#issuecomment-445830242
 SQLite's main author mentioned] that we should conform to the documented
 procedure to emulate table alterations on SQlite3.

 Right now the [https://www.sqlite.org/lang_altertable.html#caution
 SQLite's schema editor follows a procedure documented as incorrect] and
 prevents usages of the SQLite 3.26 improvements regarding table and column
 renames while foreign key constraints are disabled.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6776f5b14560823923f42308c150a5fa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30032: Can't alter the default of a DateTimeField to be TransactionNow

2018-12-11 Thread Django

#30032: Can't alter the default of a DateTimeField to be TransactionNow
-+-
 Reporter:  Gavin Wahl   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Gavin Wahl):

 This isn't a database level default, that ticket is to support defaults
 assigned by DDL. This is to support expressions as defaults.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1cbf2e1b1c0de118111bcd0b105c8a3d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30032: Allow expressions to be used for default (was: Can't alter the default of a DateTimeField to be TransactionNow)

2018-12-11 Thread Django

#30032: Allow expressions to be used for default
-+-
 Reporter:  Gavin Wahl   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * status:  closed => new
 * type:  Bug => New feature
 * version:  2.1 => master
 * resolution:  duplicate =>
 * stage:  Unreviewed => Accepted


Comment:

 Sorry about the misinterpretation, #27222 seems related and I'm pretty
 sure there's another ticket related to allowing `Now()` to be used for
 `default` but I can't find it.

 Tentatively accepting as a new feature request but as I said I'm pretty
 sure there is already another ticket tracking this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.286e53bbfa692e97aa5658a48c7237ff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30033: SQLite schema editor should use the documented to emulate table alterations on SQlite3.

2018-12-11 Thread Django

#30033: SQLite schema editor should use the documented to emulate table 
alterations
on SQlite3.
-+-
   Reporter:  Simon  |  Owner:  Simon Charette
  Charette   |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component: |Version:  master
  Migrations |
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In the light of #29182 SQLite's main author mentioned that we should
 conform to the documented procedure to emulate table alterations on
 SQlite3.

 Right now the [https://www.sqlite.org/lang_altertable.html#caution
 SQLite's schema editor follows a procedure documented as incorrect] and
 prevents usages of the SQLite 3.26 improvements regarding table and column
 renames while foreign key constraints are disabled.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.e32da1e434800fa57ae32f3ef8b77c01%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30019: Add __class_getitem__ method to managers and querysets

2018-12-11 Thread Django

#30019: Add __class_getitem__ method to managers and querysets
-+-
 Reporter:  Maxim Kurnikov   |Owner:  Greg W
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Greg W):

 I got {{{ __class_getitem__}}}  implemented.  However, I am having an
 issue with {{{models.Manager['User']}}}

 Isn't {{{'User'}}} just a string which {{{__class_getitem__}}} would not
 be valid on?  I think the idea is to index the class User, but this class
 has not been defined prior to {{{Manager[User]}}}.

 Let me know if I am off base.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.d63596c7414dc2c6898e4951a807b6c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24313: Deprecate the class_prepared signal

2018-12-11 Thread Django

#24313: Deprecate the class_prepared signal
--+
 Reporter:  Aymeric Augustin  |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Gurpreet Singh):

 * owner:  Gurpreet Singh => (none)
 * status:  assigned => new


Comment:

 Replying to [comment:8 Alex Hill]:
 > Alright, there is at least one gap in functionality: using
 `class_prepared`, you can fiddle with models in ways that propagate to
 their subclasses. In `AppConfig.ready()`, since all the `ModelBase`
 inheritance magic has already happened, it's too late to do anything like
 that.

 I shouldn't have chosen to work on this as my first ticket then it seems.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f3c02bd2c8e3583773d4a2d9723537bc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30032: Can't alter the default of a DateTimeField to be TransactionNow

2018-12-11 Thread Django

#30032: Can't alter the default of a DateTimeField to be TransactionNow
-+-
   Reporter:  Gavin  |  Owner:  nobody
  Wahl   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have this field:
 {{{
 foo = models.DateTimeField(default=timezone.now)
 }}}
 I would like to modify it to use TransactionNow instead:
 {{{
 foo = models.DateTimeField(default=TransactionNow())
 }}}
 This migration operation is generated:
 {{{
 migrations.AlterField(
 model_name='somemodel',
 name='foo',
 
field=models.DateTimeField(default=django.contrib.postgres.functions.TransactionNow()),
 ),
 }}}

 When run, this error is thrown:

 {{{
   File "./manage.py", line 29, in 
 execute_from_command_line(sys.argv)
   File "django/core/management/__init__.py", line 381, in
 execute_from_command_line
 utility.execute()
   File "django/core/management/__init__.py", line 375, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "django/core/management/base.py", line 316, in run_from_argv
 self.execute(*args, **cmd_options)
   File "django/core/management/base.py", line 353, in execute
 output = self.handle(*args, **options)
   File "django/core/management/base.py", line 83, in wrapped
 res = handle_func(*args, **kwargs)
   File "django/core/management/commands/migrate.py", line 203, in handle
 fake_initial=fake_initial,
   File "django/db/migrations/executor.py", line 117, in migrate
 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File "django/db/migrations/executor.py", line 147, in
 _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
   File "django/db/migrations/executor.py", line 244, in apply_migration
 state = migration.apply(state, schema_editor)
   File "django/db/migrations/migration.py", line 124, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "django/db/migrations/operations/fields.py", line 216, in
 database_forwards
 schema_editor.alter_field(from_model, from_field, to_field)
   File "django/db/backends/base/schema.py", line 523, in alter_field
 old_db_params, new_db_params, strict)
   File "django/db/backends/postgresql/schema.py", line 122, in
 _alter_field
 new_db_params, strict,
   File "django/db/backends/base/schema.py", line 626, in _alter_field
 old_default = self.effective_default(old_field)
   File "django/db/backends/base/schema.py", line 239, in effective_default
 return field.get_db_prep_save(default, self.connection)
   File "django/db/models/fields/__init__.py", line 790, in
 get_db_prep_save
 return self.get_db_prep_value(value, connection=connection,
 prepared=False)
   File "django/db/models/fields/__init__.py", line 1429, in
 get_db_prep_value
 value = self.get_prep_value(value)
   File "django/db/models/fields/__init__.py", line 1408, in get_prep_value
 value = super().get_prep_value(value)
   File "django/db/models/fields/__init__.py", line 1268, in get_prep_value
 return self.to_python(value)
   File "django/db/models/fields/__init__.py", line 1369, in to_python
 parsed = parse_datetime(value)
   File "django/utils/dateparse.py", line 106, in parse_datetime
 match = datetime_re.match(value)
 TypeError: expected string or bytes-like object
 }}}

 If I create the field foo from scratch, with an AddField operation instead
 of AlterField, it works as expected.

 I should be able to modify a field to use TransactionNow() as a default.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.8c03ee2bb471c66c8d2b1bb7ad8aa34f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30022: Doc how to combine post_save signal with on_commit to alter a m2m relation when saving a model instance

2018-12-11 Thread Django

#30022: Doc how to combine post_save signal with on_commit to alter a m2m 
relation
when saving a model instance
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by George Tantiras):

 Replying to [comment:1 Simon Charette]:
 > `do_something()` would never be called because
 `validate_and_add_to_group()`'s `save()` calls that would trigger the
 `post_save` receiver would only queue the group additions to be performed
 `on_commit` which wouldn't happen until the `accept_group_invite` function
 exits.

 The above is very clear and understood.

 I made [https://github.com/raratiru/django-testing-on-commit an effort] to
 replicate the below quote:

 > If you want to make sure both `save()` and its `pre_save` and
 `post_save` side effects are performed in as an atomic operation (either
 succeed or fail) then you should simply wrap your `save()` calls in an
 `atomic` block.

 In my bare django project I plugged [https://github.com/raratiru/django-
 testing-on-commit/blob/master/user/signals.py user/signals.py] and
 [https://github.com/raratiru/django-testing-on-
 commit/blob/master/user/test_user.py user/test_user.py] to test under
 which circumstances the signal will successfully add the saved user
 instance to the 'Superuser' group.

 The result is that both `transaction_atomic()` and
 `transaction.on_commit()` are needed.

 I report this, just in case it is an unexpected behavior.

 {{{

 def test_user(group, user_data, superuser_data):
 '''
 If transaction.on_commit() is not used in the receiver, this test will
 fail.
 '''
 # Add a user
 creation_form = UserCreationForm(data=user_data)
 user = creation_form.save()
 # Make the new user a Superuser
 change_form = UserChangeForm(instance=user, data=superuser_data)
 with transaction.atomic():
 superuser = change_form.save()

 assert group in superuser.groups.all(), "Although is_superuser is
 True, the user is not in the Superuser group"


 def test_user_non_atomic(group, user_data, superuser_data):
 '''
 This will fail because transaction.atomic() is not used.
 '''
 creation_form = UserCreationForm(data=user_data)
 user = creation_form.save()
 change_form = UserChangeForm(instance=user, data=superuser_data)
 superuser = change_form.save()

 assert group in superuser.groups.all(), "Although is_superuser is
 True, the user is not in the Superuser group"
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.8a2e06cf41e0c6747c7eec5a824b1c2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30022: Doc how to combine post_save signal with on_commit to alter a m2m relation when saving a model instance

Re: [Django] #29928: TestCase doesn't check for foreign key constraints when using sqlite

Re: [Django] #29981: "Please correct the error below." (with no errors displayed) when changing an inline that has a one-to-one relation to the parent that uses to_field

Re: [Django] #30032: Can't alter the default of a DateTimeField to be TransactionNow

Re: [Django] #30033: SQLite schema editor should use the documented to emulate table alterations on SQlite3.

Re: [Django] #30033: SQLite schema editor should use the documented to emulate table alterations on SQlite3.

Re: [Django] #30032: Can't alter the default of a DateTimeField to be TransactionNow

Re: [Django] #30032: Allow expressions to be used for default (was: Can't alter the default of a DateTimeField to be TransactionNow)

[Django] #30033: SQLite schema editor should use the documented to emulate table alterations on SQlite3.

Re: [Django] #30019: Add __class_getitem__ method to managers and querysets

Re: [Django] #24313: Deprecate the class_prepared signal

[Django] #30032: Can't alter the default of a DateTimeField to be TransactionNow

Re: [Django] #30022: Doc how to combine post_save signal with on_commit to alter a m2m relation when saving a model instance

13 matches

Site Navigation

Mail list logo

Footer information