benefacto
commented
3 years ago We're experiencing this issue on a project we're working on and it's making the package unusable for us. It occurs when we load the templates that use flags and on the admin dashboard when we navigate to the flag states. We don't experience the error locally--just on our hosted application (on Heroku):
UndefinedTable: relation "flags_flagstate" does not exist
LINE 1: ...state"."value", "flags_flagstate"."required" FROM "flags_fla...
^
File "django/db/backends/utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
ProgrammingError: relation "flags_flagstate" does not exist
LINE 1: ...state"."value", "flags_flagstate"."required" FROM "flags_fla...
^
File "django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "django/core/handlers/base.py", line 115, in _get_response
response = self.process_exception_by_middleware(e, request)
File "django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "django/contrib/admin/options.py", line 606, in wrapper
return self.admin_site.admin_view(view)(*args, **kwargs)
File "django/utils/decorators.py", line 142, in _wrapped_view
response = view_func(request, *args, **kwargs)
File "django/views/decorators/cache.py", line 44, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
File "django/contrib/admin/sites.py", line 223, in inner
return view(request, *args, **kwargs)
File "django/contrib/admin/options.py", line 1645, in add_view
return self.changeform_view(request, None, form_url, extra_context)
File "django/utils/decorators.py", line 45, in _wrapper
return bound_method(*args, **kwargs)
File "django/utils/decorators.py", line 142, in _wrapped_view
response = view_func(request, *args, **kwargs)
File "django/contrib/admin/options.py", line 1529, in changeform_view
return self._changeform_view(request, object_id, form_url, extra_context)
File "django/contrib/admin/options.py", line 1586, in _changeform_view
form = ModelForm(initial=initial)
File "flags/forms.py", line 25, in __init__
(f, f) for f in sorted(get_flags().keys())
File "flags/sources.py", line 183, in get_flags
source_flags = source_obj.get_flags()
File "flags/sources.py", line 136, in get_flags
for o in self.get_queryset():
File "django/db/models/query.py", line 274, in __iter__
self._fetch_all()
File "django/db/models/query.py", line 1242, in _fetch_all
self._result_cache = list(self._iterable_class(self))
File "django/db/models/query.py", line 55, in __iter__
results = compiler.execute_sql(chunked_fetch=self.chunked_fetch, chunk_size=self.chunk_size)
File "django/db/models/sql/compiler.py", line 1142, in execute_sql
cursor.execute(sql, params)
File "django/db/backends/utils.py", line 67, in execute
return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
File "django/db/backends/utils.py", line 76, in _execute_with_wrappers
return executor(sql, params, many, context)
File "django/db/backends/utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
File "django/db/utils.py", line 89, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
File "django/db/backends/utils.py", line 84, in _execute
return self.cursor.execute(sql, params)Essentially, everything works fine locally and we're using the example in two of our templates similar to the following:
base.html
{% load feature_flags %}
{% flag_enabled 'MY_FLAG1' as my_flag1_enabled %}
{% if my_flag1_enabled %}
<div class="flagged-banner">
I’m the result of a feature flag.
</div>
{% endif %}template.html
{% extends 'base.html' %}
{% load feature_flags %}
{% flag_enabled 'MY_FLAG2' as my_flag2_enabled %}
{% if my_flag1_enabled %}
<div class="flagged-banner">
I’m the result of a feature flag.
</div>
{% endif %}Then, in our settings, we're configuring the flags' conditions:
## Feature flags configuration
FLAGS = {
"MY_FLAG1": [
{"condition": "parameter", "value": "enable_flag1"},
],
"MY_FLAG2": [
{"condition": "parameter", "value": "enable_flag2"},
],
}This is meaning that we're going to have to use environment variables to roll our own feature flags rather than using this library. We'd prefer to use this library as it has plenty of functionality and seems well maintained. We'd appreciate any help anyone can offer.
willbarton
The Django check introduced in #16 has a dependency on the database due to the way that it validates flag conditions. Unfortunately Django checks may run at times when the database hasn't been created, or is unavailable.
For example, starting in a fresh project with no database and running
manage.py migratewill try to execute the Django checks before the database tables are created. This will result in a stack trace like this:It looks like #17 is proposing a fix for this, although there might be a better/alternate way to handle that's a little more targeted (i.e. ignoring all exceptions would hide any real database errors).