sqlalchemy.exc.NoInspectionAvailable when column_filters refers to a string-referenced relationship using SQAlchemy 1.3.16

String-referenced relationships (e.g. relationship("Parent") rather than relationship(Parent)) cannot be be referred to in column_filters (and perhaps other properties too) without raising sqlalchemy.exc.NoInspectionAvailable on the latest version of SQLAlchemy (1.3.16, released yesterday).

Here’s a minimal example:

from flask import Flask
from flask_admin import Admin
from flask_admin.contrib.sqla import ModelView
from sqlalchemy import Column, ForeignKey, Integer, String, create_engine
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import relationship, sessionmaker

Base = declarative_base()


class Parent(Base):
    __tablename__ = "parent"
    id = Column(Integer, primary_key=True)
    name = Column(String)


class Child(Base):
    __tablename__ = "child"
    id = Column(Integer, primary_key=True)
    parent_id = Column(Integer, ForeignKey("parent.id"))
    parent = relationship("Parent")


class ChildView(ModelView):
    column_filters = ["parent.name"]


app = Flask(__name__)
admin = Admin(app, name="Admin")
engine = create_engine("sqlite:///:memory:", echo=True)
Session = sessionmaker(bind=engine)

# Fails with NoInspectionAvailable on sqlalchemy>=1.3.16
admin.add_view(ChildView(Child, Session))

Traceback:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/tmp/pip-run-ulfvhtlu/flask_admin/contrib/sqla/view.py", line 330, in __init__
    menu_icon_value=menu_icon_value)
  File "/tmp/pip-run-ulfvhtlu/flask_admin/model/base.py", line 818, in __init__
    self._refresh_cache()
  File "/tmp/pip-run-ulfvhtlu/flask_admin/model/base.py", line 945, in _refresh_cache
    self._refresh_filters_cache()
  File "/tmp/pip-run-ulfvhtlu/flask_admin/model/base.py", line 847, in _refresh_filters_cache
    self._filters = self.get_filters()
  File "/tmp/pip-run-ulfvhtlu/flask_admin/model/base.py", line 1161, in get_filters
    flt = self.scaffold_filters(n)
  File "/tmp/pip-run-ulfvhtlu/flask_admin/contrib/sqla/view.py", line 661, in scaffold_filters
    is_hybrid_property = tools.is_hybrid_property(self.model, name)
  File "/tmp/pip-run-ulfvhtlu/flask_admin/contrib/sqla/tools.py", line 209, in is_hybrid_property
    return last_name in get_hybrid_properties(last_model)
  File "/tmp/pip-run-ulfvhtlu/flask_admin/contrib/sqla/tools.py", line 190, in get_hybrid_properties
    for key, prop in inspect(model).all_orm_descriptors.items()
  File "/tmp/pip-run-ulfvhtlu/sqlalchemy/inspection.py", line 72, in inspect
    "available for object of type %s" % type_
sqlalchemy.exc.NoInspectionAvailable: No inspection system is available for object of type <class 'method'>

This works fine with SQLAlchemy 1.3.15. My guess is that it’s to do with the use of _class_resolver in flask_admin.contrib.sqla.tools.

[mrjoes]

Thanks for the quick workaround, I’ll get it merged ASAP.

Most of the original inspection code was written in 2012, before the official SQLAlchemy inspection API. Originally was never refactored to keep backwards compatibility and later because it was fairly stable.

But yes, this particular feature was contributed later in 2016 when inspection API already existed.

@zzzeek What would be the approach with configure_mappers(), assuming we’re handling columns differently than hybrid properties in filters and need to differentiate between two?

[mrjoes]

Thank you! I pushed the hot fix release before I saw the second version of the fix. I’m going to check the second version and merge it into the master branch.

I’ll also try to figure out how to add configure_mappers() safely, but this is going to be tricky. Flask-Admin does not dictate how Flask applications should be initialized and attempts to resolve things early to fail right away if something is wrong. That being said - configure_mappers() might introduce unwanted side-effects for a partially initialized application, as for larger apps its natural to split them into smaller manageable pieces that have their own models, views, etc. I guess it would be better to delay the initialization until after configure_mappers(), but this will require some refactoring and might also break some real world applications.