Hi Simon,
Thank you very much for your prompt reply! I've added the following to my
app, which seems to work just fine:
@receiver(models.signals.post_migrate)
def gen_site_config_post_migrate(plan, **kwargs):
# A migration of the `django.contrib.sites` app was applied.
if plan and any(migration.app_label == 'sites' for migration, _ in
plan):
try:
site = Site.objects.get(name='example.com')
except ObjectDoesNotExist:
pass
else:
SiteConfig.objects.get_or_create(
site=site,
admin_email='ad...@example.com',
remote=False
)
It seems the code inside the if statement is called several times (7, to be
exact) when I run initial migrations, with the site finally getting created
at the end. This is why I've had to add some exception handling for when
the site doesn't exist.
Simon, one last question for you -- where should this code live? I
currently have it shoved in my model file but that doesn't feel quite right.
Thank you again!
--Matt
On Saturday, September 10, 2016 at 10:42:16 PM UTC-4, Simon Charette wrote:
>
> Hi Matt,
>
> I worked on the changes that broke your code.
>
> Starting with 1.10 the migration signals are passed an `apps` kwarg
> representing
> the state of models before and after the specified migrations are applied.
>
> This allows signal receivers to manipulate model definitions that are
> synchronized with their actual database representation just like a data
> migrations would (e.g. `RunPython` operations).
>
> Before this change was introduced the signal receivers were performing
> queries
> using the globally available model definitions which could lead to failures
> when querying the underlying tables as their schema were not synchronized
> with
> their global model definitions.
>
> In your case, the signals you attached to the global `Site` model are not
> fired
> anymore as the queries are performed using the migration specific one which
> you cannot attach listeners to.
>
> It's hard for me to come up with a complete solution without the actual
> code
> attached to `post_save(sender=Site)` but something along these lines
> should do:
>
> @receiver(post_migrate)
> def sync_site(plan, **kwargs):
> # A migration of the `django.contrib.sites` app was applied.
> if plan and any(migration.app_label == 'sites' for migration, _ in
> plan):
> # ... perform actions
>
> Let me know if you need more details,
> Simon
> Le samedi 10 septembre 2016 21:59:56 UTC-4, Matt Thompson a écrit :
>>
>> Hi All,
>>
>> I have a small Django app that uses the sites framework and has a
>> post_save signal on Site that does some bits and bobs when a new site is
>> created. On 1.9.7, when you run migrations for the first time, it
>> correctly triggers the post_save signal. However, after upgrading to
>> 1.10.1, dropping the database, and re-running migrations, the post_save
>> signal I have setup on Site doesn't seem to be triggering. I tried reading
>> the 1.10 release notes and while there was mention of a pre_migrate() and
>> post_migrate() signals, I couldn't make heads or tails on whether that is
>> related.
>>
>> If this is a deliberate change, can someone please point me to the
>> specifics? If it's a bug, I'd be more than happy to file a bug.
>>
>> Thanks!
>>
>> --Matt
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/dfc9ae9c-d7fb-4f2a-a857-bae133f92b03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
