In a nutshell -- the call to execute isn't touching the ORM level; just
the sqlalchemy core. As such, it's not marking things as changed. Not
sure why a rollback is preferred to no activity, but my guess would be
it's easier on replication.
According to the log, the transaction is neither committed nor rolled back.
If you call a dbSession.flush(), you should be able to generate an event
that marks the session as changed, and will enable the commit.
DBSession.flush() doesn't enable the commit/rollback.
For the sake of completeness, here's my re-worked code (the strange
workaround enables the commit):
@view_config(route_name='upload')
def upload_view(request):
shotFile = request.POST['siusshots'].file
insertOrIgnore = SiusShot.__table__.insert(
append_string = "ON DUPLICATE KEY UPDATE shotId=shotId")
DBSession.execute(
insertOrIgnore,
[shot.__dict__ for shot in ShotReader(shotFile)])
# Workaround to make sure the transaction gets committed
DBSession.merge(SiusShot(
startNbr = 0,
laneNbr = 0,
dateTime = 0,
primaryScore = 0))
dummyShot = DBSession.query(SiusShot).filter_by(
startNbr = 0,
laneNbr = 0,
dateTime = 0,
primaryScore = 0).delete()
return Response('OK')
--
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/groups/opt_out.
