Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KeyError / versioning_manager.units_of_work #187

Open
dfee opened this issue Apr 3, 2018 · 2 comments
Open

KeyError / versioning_manager.units_of_work #187

dfee opened this issue Apr 3, 2018 · 2 comments

Comments

@dfee
Copy link

dfee commented Apr 3, 2018

I spent a good deal of time today working through this problem, and I figured I should document it here. The error becomes apparent when a user tries to flush objects that are versioned, but the session is not being tracked by the versioning_manager. A KeyError exception is raised as the session is not in versioning_manager.units_of_work.

make_versioned by default uses the default session factory for sqlalchemy (sqlalchemy.orm.session.Session). This behavior cannot be overridden either – versioning_manager.track_session(...) is called for whatever value is provided (i.e. None is not allowed, as an exception is thrown).

This is probably not a good idea, as common practices like dependency-injection break this. An example would be if a user is to generate his own session factory using sqlalchemy.orm.session.sessionmaker (as is encouraged).

Anyway, the solution here is to call versioning_manager.track_session(my_session_factory) with the my_session_factory the user has generated from sessionmaker.

@dalymople
Copy link

I also came across this issue when using SQLAlchemy-Continuum==1.3.6 with Flask, the FlaskPlugin and Flask-SQLAlchemy.

I found the best way around this was to pass the session factory at creation of the make_versioned class;
make_versioned(session=db.session, plugins=[FlaskPlugin()])

Maybe the docs the docs should be updated to state that you need to explicitly pass the session factory if you are not using the default factory?

@AbdealiLoKo
Copy link
Contributor

This was happening due to the bug in sqlalchemy: sqlalchemy/sqlalchemy#8467
This ticket can be closed as sqlalchemt 1.4.41 is released which fixes this bug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants