versioned_history example no longer works with sqlalchemy 2.0

[martell]

Describe the bug

The versioned_history example relies on sqlalchemy.orm.mapper which was deprecated in 1.4 and removed in 2.0.

https://docs.sqlalchemy.org/en/14/orm/mapping_api.html#sqlalchemy.orm.mapper
https://docs.sqlalchemy.org/en/20/orm/mapping_api.html#sqlalchemy.orm.mapper

With sqlalchemy 1.4 I was able to replace mapper with map_imperatively.
With sqlalchemy 2.0 the same attempted change errors out due to changes in 5ec5b0a

To reproduce

python3 -m unittest examples/versioned_history/test_versioning.py

Error

Running the example

sqlalchemy.exc.InvalidRequestError: The 'sqlalchemy.orm.mapper()' function is removed as of SQLAlchemy 2.0. 
Use the 'sqlalchemy.orm.registry.map_imperatively()` method of the ``sqlalchemy.orm.registry`` class to perform classical mapping.

Running the example with attempting to change mapper with map_imperatively

File "sqlalchemy/orm/decl_api.py", line 1357, in _add_manager
    assert manager.registry is None

Versions

• SQLAlchemy: 2.0+

Additional context

No response

[zzzeek]

oh it's not working yet, OK , sorry missed that

[zzzeek]

so to make it "work", first off the test_verisoning.py has a fixture which assumes pytest, does not work with python -m unittest so we do as it documents:

cd examples/versioned_history
pytest test_versioning.py

if we want to make it compatible with python -m unittest or even better just make it unittest runnable that would be good. not sure why on earth I made this one example depend on pytest. very strange

next, the way that map_imperatively() works now is not a direct port of mapper(), so the particular hook that's being used here, __mapper_cls__, which fortunately seems to be undocumented, has to actually return the Mapper class, not the mapper function's equivalent anymore.

so it all works with this patch:

diff --git a/examples/versioned_history/history_meta.py b/examples/versioned_history/history_meta.py
index 23bdc1e6f8..197fb68399 100644
--- a/examples/versioned_history/history_meta.py
+++ b/examples/versioned_history/history_meta.py
@@ -11,7 +11,6 @@ from sqlalchemy import Table
 from sqlalchemy import util
 from sqlalchemy.ext.declarative import declared_attr
 from sqlalchemy.orm import attributes
-from sqlalchemy.orm import mapper
 from sqlalchemy.orm import object_mapper
 from sqlalchemy.orm.exc import UnmappedColumnError
 from sqlalchemy.orm.relationships import RelationshipProperty
@@ -151,7 +150,7 @@ def _history_mapper(local_mapper):
         bases = local_mapper.base_mapper.class_.__bases__
     versioned_cls = type.__new__(type, "%sHistory" % cls.__name__, bases, {})
 
-    m = mapper(
+    m = local_mapper.registry.map_imperatively(
         versioned_cls,
         table,
         inherits=super_history_mapper,
@@ -172,6 +171,7 @@ def _history_mapper(local_mapper):
         if cls.use_mapper_versioning:
             local_mapper.version_id_col = local_mapper.local_table.c.version
 
+from sqlalchemy.orm import Mapper
 
 class Versioned:
     use_mapper_versioning = False
@@ -180,7 +180,7 @@ class Versioned:
     @declared_attr
     def __mapper_cls__(cls):
         def map_(cls, *arg, **kw):
-            mp = mapper(cls, *arg, **kw)
+            mp = Mapper(cls, *arg, **kw)
             _history_mapper(mp)
             return mp
 

however that fix sucks. I am not able to get a better fix working right now as the history thing seems to work in an extremely specific way. so far it's looking like I have to add a new mapper configuration hook, this will require some effort.

[sqla-tester]

Mike Bayer has proposed a fix for this issue in the main branch:

WIP - port history meta to 2.0 https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/4422

[zzzeek]

the attempts im making to restore this in a better way are suggesting that this might benefit from adding a new mapper event after_mapper_constructed, just to get in that spot. this spot has the following special things:

1. the polymorphic_on is actually configured here
2. we can add things to the mapper, or make new mappers, without the need for configure_mappers() to be called
3. if we do make new mappers, they will get configured on the next configure() call
4. we can iterate through the mapper's properties

there's no other hook right now that has all those things at once.