In the course of parsing / changing someone else's code, errors occur when synchronizing dependent entities (Person - Child) during the synchronization script. Apparently, there is such a situation that session.add(person) tries to add to the database the orm-Child object that was previously deleted by the synchronizer:

  session.add(person) File "/home/web/portal/env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 1559, in add self._save_or_update_state(state) File "/home/web/portal/env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 1578, in _save_or_update_state self._save_or_update_impl(st_) File "/home/web/portal/env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 1828, in _save_or_update_impl self._update_impl(state) File "/home/web/portal/env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 1814, in _update_impl state_str(state) InvalidRequestError: Instance '<Child at 0xec10afec>' has been deleted. Use the make_transient() function to send this object back to the transient state.

  1. What does marking the object make_transient() mean make_transient() How and why should it be used in such a context?

  2. In the course of the code, another strategy of deleting objects with one request is also used: via .delete() . The question is what gives such requests and when the synchronize_session flag is used?

session.query(Child).filter(Child.id==child.id).delete(synchronize_session=False)

    1 answer 1

    The session.query(Child).delete() will not only remove the corresponding records from Child objects from the database, but also update the state of these objects in the session. Naturally, these additional steps take time and will slow down the removal process accordingly. If you know for sure what's next in the code you will no longer access these objects, then you have no reason to update their state. For this, synchronize_session=False also serves. But judging by the errors you have, you still appeal to them. Therefore, remove the synchronize_session parameter from delete() and check if the problem occurs.

    • Yes, thanks, I figured it out in general, left deleting with synchronize_session = False, cleaned the extra flush from the code just in case. The problem for the production was not at all in this, but the fact that the test server did not turn off sending errors to the common pool along with the production and parallel for some time another synchronizer worked with its base. - PaiNt