Okay thank you both for the help. I'm now checking for changes before
accessing relationships that might flush. Basically:
if has_changes(self): write_revision(self)
Should do the trick. Seems to be working already.
On Monday, May 7, 2018 at 9:33:27 PM UTC-7, Jonathan Vanasco wrote:
>
>
>
>
On Monday, May 7, 2018 at 10:27:03 PM UTC-4, Mike Bayer wrote:
>
> can you perhaps place a "pdb.set_trace()" inside of session._flush()?
> using the debugger you can see the source of every flush() call.
> Generally, it occurs each time a query is about to emit SQL.
>
>
Building off what Mike
can you please just post a simple failing test? there's nothing
unusual about any of these stack traces. I don't know what you're
trying to do.
On Mon, May 7, 2018 at 10:52 PM, Colton Allen wrote:
> Sorry to spam you. The logs didn't paste in full.
>
>
> api_1 |
Sorry to spam you. The logs didn't paste in full.
api_1 | Traceback (most recent call last):
api_1 | File
"/usr/local/lib/python3.5/site-packages/werkzeug/wsgi.py", line 660, in
__call__
api_1 | return app(environ, start_response)
api_1 | File
I think I did it right. The logs just didn't scroll up. This might be
causing the issue (account is a orm.relationship).
api_1 | File "/app/models/post/__init__.py", line 160, in
manage_review_status
api_1 | if not target.account.settings.compliance_enable_post:
Full logs:
New to pdb. Does this look correct?
class DebugSession(Session):
def _flush(self, objects=None):
pdb.set_trace()
super()._flush(objects)
factory = sqlalchemy.orm.sessionmaker(bind=engine, class_=DebugSession)
Program terminates when trying to call _flush().
api_1 | >
What exactly causes the session to flush? I'm trying to track down a nasty
bug in my versioning system.
Sorry for the long code dump. I retooled
examples/versioned_history/history_meta.py so it should look familiar. The
function that's breaking is "column_has_changed". I've added some logs