How do SQLAlchemy's identity map and unit of work affect ORM behavior?

For large batches I watch how many tracked objects the Session retains and flush or partition work deliberately without pretending flush commits it. Database constraints remain authoritative because the unit of work coordinates only this Session, not other processes. If a bulk statement changes rows outside normal ORM tracking, I expire affected objects or isolate that operation so stale instances are not reused. I diagnose surprising writes by inspecting object state, dirty collections, cascades, emitted SQL, and the transaction boundary rather than assuming assignment immediately updated the database.