Re: [sqlalchemy] 0.9.7: Intermittently find a dead weakref to a listens_for function while checking _stored_in_collection of a registry
Michael, Thanks - sorry to have wasted your time. It seems I gave up on Googling my stack trace too soon. Thanks, Evan James -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] 0.9.7: Intermittently find a dead weakref to a listens_for function while checking _stored_in_collection of a registry
Hi folks, While running my test suite, I hit an issue with the following stack trace: ERROR at setup of test_track_before_delete request = SubRequest 'database_session' for Function 'test_track_before_delete', engine = Engine(sqlite:///test.db) @pytest.fixture def database_session(request, engine): connection = engine.connect() trans = connection.begin() meta.Session = scoped_session(sessionmaker(autocommit=False, autoflush=True, bind=connection)) register_session_listeners(meta.Session) meta.Session.begin_nested() @event.listens_for(meta.Session, after_transaction_end) def restart_savepoint(session, transaction): if transaction.nested and not transaction._parent.nested: automated_tests/conftest.py:52: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ../../../.virtualenvs/ERP/lib/python2.7/site-packages/sqlalchemy/event/api. py:94: in decorate listen(target, identifier, fn, *args, **kw) ../../../.virtualenvs/ERP/lib/python2.7/site-packages/sqlalchemy/event/api. py:63: in listen _event_key(target, identifier, fn).listen(*args, **kw) ../../../.virtualenvs/ERP/lib/python2.7/site-packages/sqlalchemy/event/ registry.py:187: in listen self.dispatch_target.dispatch._listen(self, *args, **kw) ../../../.virtualenvs/ERP/lib/python2.7/site-packages/sqlalchemy/event/base. py:184: in _listen event_key.base_listen(propagate=propagate, insert=insert, named=named) ../../../.virtualenvs/ERP/lib/python2.7/site-packages/sqlalchemy/event/ registry.py:226: in base_listen for_modify(target.dispatch).append(self, propagate) ../../../.virtualenvs/ERP/lib/python2.7/site-packages/sqlalchemy/event/attr. py:118: in append registry._stored_in_collection(event_key, self) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ event_key = sqlalchemy.event.registry._EventKey object at 0x111c6b3d0, owner = sqlalchemy.event.attr._DispatchDescriptor object at 0x10eac8590 def _stored_in_collection(event_key, owner): key = event_key._key dispatch_reg = _key_to_collection[key] owner_ref = owner.ref listen_ref = weakref.ref(event_key._listen_fn) if owner_ref in dispatch_reg: assert dispatch_reg[owner_ref] == listen_ref E assert weakref at 0x111cc25d0; dead == weakref at 0x111cc2af8 ; to 'function' at 0x111c7f668 (restart_savepoint) ../../../.virtualenvs/ERP/lib/python2.7/site-packages/sqlalchemy/event/ registry.py:74: AssertionError While running the @event.listens_for decorator in the setup of a test fixture, SQLAlchemy throws an assertion because the ref it has in the dispatch registry isn't identical to the ref to the listener function. We're on SQLAlchemy 0.9.7, pytest 2.6.4. Note that the test suite is setting up nested transactions on SQLite; we are using the recommended workaround from SQLAlchemy documentation to take control of transactional integration from pysqlite. Since there's an assertion in the code in _stored_in_collection(), I assume that there's some expectation that the refs might not match; am I doing something wrong in my setup which this assertion is meant to catch? I've only seen this error once (while tracking down a different nondeterministic error in my own app's code), so I can't provide much more information than this, but the portion of test fixture code seen above in the stack trace is basically the entire reproduction case. This fixture runs before every test in my suite, but I've only seen an error once across a large number of runs, so the error is *very* intermittent. Because of that, I'm not worried too much about the error itself, but I thought I should post it here in case it's a symptom of something I should be worrying about. Thanks, Evan James -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Relationship behavior change when switching from reflected to declarative styles; test case included
On Tuesday, March 3, 2015 at 4:41:20 PM UTC-5, Michael Bayer wrote: Essentially the issue is likely because the mappings in these two examples are not equivalent; the reflection based version has Widget.frobnicator and Frobnicator.widget communicating with each other through a backref, and the declarative version does not. Thanks, Michael. Yes, we're on SQLAlchemy 0.9. We used a script to generate the declarative models by introspecting on the reflective ones, and in the process it turned a relationship defined once with a backref into two relationships defined without using the backref keyword. We missed that the backref argument is responsible for the event listeners as well as for creating the relationship on the other model. Adding the back_populates argument to the model declarations fixes our issue. Thanks, Evan James -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Relationship behavior change when switching from reflected to declarative styles; test case included
Hi folks, I'm working on a SQLAlchemy-based app where we've decided to make some infrastructure changes, in particular moving from reflection to declaration for mapping the models. However, we're now running into issues where, after switching to declarative, relationships aren't populated the way we expect when manipulated in Python. For example, we have code that looks like this: class Widget(...): def merge(self, other_widget): Merge the widgets, transferring the dependent items on the other widget to this one. for frobnicator in other_widget.frobnicators[:]: frobnicator.widget = self meta.Session.delete(other_widget) This code worked as hoped-for when we were reflecting on the database to create our mappers, but after switching to declarative, the dependent items are cascade-deleted on commit when other_widget is deleted, rather than being preserved as children of the merged widget. It's not difficult to fix this particular issue - explicitly removing the frobnicators from the other_widget.frobnicators collection will prevent them from being deleted, and then the merged widget correctly has them - but we're finding we have a class of bugs where relationships aren't being handled the same way as before. Unfortunately, build a comprehensive test suite is one of the infrastructure changes we're in the process of making - which means it's not done yet and we can't easily track down all the places we could get tripped up. We would really prefer to resolve this by changing the definitions in the models, not by changing the application code that manipulates the membership of relationships. I've created a reduced test case here https://github.com/ejames/sqlalchemy_reflection_problem_reduction which specifically displays the behavior we're having trouble with in minimal form. If one line in the test case is commented out, the test will pass for reflective models and fail for declarative models; if the line is put back in, success and failure reverse. My question: How can we make relationships function identically in declarative syntax as they did in reflective syntax? We thought we had migrated mapping styles in a way that wouldn't change anything, but here we are. What are we missing? Thanks, Evan James -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
