Django 1.9 and relation "django_facebook_open_graph_share" does not exist

[turukawa]

I've been upgrading a Django project to 1.9 and get the following error with Django Facebook:

ProgrammingError at /admin/django_facebook/opengraphshare/
relation "django_facebook_open_graph_share" does not exist
LINE 1: SELECT COUNT(*) AS "__count" FROM "django_facebook_open_grap...

I've installed the Django Facebook 6.0.4 version from Master which is mostly Django 1.9 compliant (and I fixed the urlpatterns in urls.py for my version).

On my build the error is simple enough to reproduce. Go into the admin view and select Open graph shares. Instant chaos.

I've seen the discussion for https://github.com/tschellenbach/Django-facebook/issues/523 by @amarpreetsaini but there doesn't seem to be any resolution to that, and I'm not sure if this is new and related to 1.9.

I'm less interested in the OpenGraphShare problem than that this prevents me deleting users (results in the same error message).

Any ideas?

[turukawa]

UPDATE: this seems a very terrible and stupid hack, but - after the database has been created - if I directly edit the table name from 'django_facebook_opengraphshare' to 'django_facebook_open_graph_share' it works.

I don't feel comfortable doing this, so would prefer a more lasting solution. Any thoughts?

[jrabbit]

So this appears to be because of https://github.com/tschellenbach/Django-facebook/blob/e91e389f463743f64917fa840a40a72513008b60/django_facebook/models.py#L531 which #django says is bad.

@tschellenbach: What's the benefit of having the complex table renaming like in https://github.com/tschellenbach/Django-facebook/blob/e91e389f463743f64917fa840a40a72513008b60/django_facebook/models.py#L369? Doesn't django do it for you?

[jsvaughan]

As a workaround note that:

• You can tell django-facebook explicitly what this table is called with this setting: FACEBOOK_OG_SHARE_DB_TABLE= 'django_facebook_open_graph_share'

• But you will still get this problem when, for example, running tests, because django attempts to serialize the database contents so it can do a pseudo rollback even if you aren't using transactions (I know - this was news to me too). Given that you are bound to be using transactions, you can set the SERIALIZE django parameter to False (see https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-TEST_SERIALIZE) and this will stop it trying to query the table contents prior to running the tests. e.g.

  DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', ... 'TEST': { 'SERIALIZE': False, } },

I'm part way through a django upgrade so YMMV but I am at least able now to run my test suite

[Jiloc]

still no fixes? I am running in to this right now