Browsing to newly created table fails with ArgumentError

[pajot]

I can now create tables using the Wizard. Afterwards, the user agent is redirected to the table URL and an ArgumentError is thrown:

Exception Type: ArgumentError at /dataedit/view/model_draft/test
Exception Value: The argument passed to Dialect.has_table() should be a <class 'sqlalchemy.engine.base.Connection'>, got <class 'sqlalchemy.engine.base.Engine'>. Additionally, the Dialect.has_table() method is for internal dialect use only; please use ``inspect(some_engine).has_table(<tablename>>)`` for public API use.

What do I need to change to resolve this?

The complete error output follows.

Environment:


Request Method: GET
Request URL: http://postgres.monitoring:8000/dataedit/view/model_draft/test

Django Version: 3.2.11
Python Version: 3.8.10
Installed Applications:
('django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'django.contrib.sessions.backends.signed_cookies',
 'bootstrap4',
 'rest_framework',
 'rest_framework.authtoken',
 'modelview',
 'modelview.templatetags.modelview_extras',
 'login',
 'base',
 'base.templatetags.base_tags',
 'widget_tweaks',
 'dataedit',
 'colorfield',
 'literature',
 'api',
 'ontology',
 'axes',
 'captcha',
 'django.contrib.postgres',
 'fontawesome_5',
 'tutorials',
 'jquery',
 'django_better_admin_arrayfield')
Installed Middleware:
('django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'django.middleware.security.SecurityMiddleware',
 'login.middleware.DetachMiddleware',
 'axes.middleware.AxesMiddleware')



Traceback (most recent call last):
  File "/home/sfbosch/oep-website/oep-website/lib/python3.8/site-packages/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/home/sfbosch/oep-website/oep-website/lib/python3.8/site-packages/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/sfbosch/oep-website/oep-website/lib/python3.8/site-packages/django/views/generic/base.py", line 70, in view
    return self.dispatch(request, *args, **kwargs)
  File "/home/sfbosch/oep-website/oep-website/lib/python3.8/site-packages/django/views/generic/base.py", line 98, in dispatch
    return handler(request, *args, **kwargs)
  File "/home/sfbosch/oep-website/./dataedit/views.py", line 877, in get
    if not engine.dialect.has_table(engine, table, schema=schema):
  File "/home/sfbosch/oep-website/oep-website/lib/python3.8/site-packages/sqlalchemy/dialects/postgresql/base.py", line 3390, in has_table
    self._ensure_has_table_connection(connection)
  File "/home/sfbosch/oep-website/oep-website/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 341, in _ensure_has_table_connection
    raise exc.ArgumentError(

Exception Type: ArgumentError at /dataedit/view/model_draft/test
Exception Value: The argument passed to Dialect.has_table() should be a <class 'sqlalchemy.engine.base.Connection'>, got <class 'sqlalchemy.engine.base.Engine'>. Additionally, the Dialect.has_table() method is for internal dialect use only; please use ``inspect(some_engine).has_table(<tablename>>)`` for public API use.

[MGlauer]

Could you specify which SQLAlchemy version you are using?

[pajot]

Could you specify which SQLAlchemy version you are using?

1.4.31.

[MGlauer]

This looks like a version issue. @wingechr Do you know the version with which the latest release was tested? I am a bit out of the loop, but SQLAlchemy has a tendency to have breaking minor releases :/

[pajot]

What's the better response?

• modify the code to make it run with SQLAlchemy 1.4.31, or
• pin the SQLAlchemy version to one that works with the code as is?

Personally, I think readying the OEP for later versions of SQLAlchemy is the wiser approach. There are likely good reasons for these design changes.

[pajot]

Okay, I have downgraded to SQLAlchemy 1.3.24, which is an official maintenance release. That resolves the problem.

If you rely on a stable long-term release, then it's a good idea to pin the dependency to that major version.