On Tuesday, August 16, 2022 at 11:45:24 AM UTC-4 Mike Orr wrote: > It is rolling back in some of my testing when there's no > insert/delete/update, but I want to make sure it always does, just in > case something somehow modifies the database when we didn't intend to. > It's not that big a deal but it's what I'd like. I'm not sure if > SQLAlchemy is issuing rollback if there were no changes, or if it will > always do so.
That's from SQLAlchemy. It will rollback if there were no database writes. SQLAlchemy is unaware of raw sql being a write operation, so you need to use the `mark_changed` function from zope.sqlalchemy. This is a weird idiosyncrasy of SQLAlchemy and transaction - the transaction could be completely successful, but SQLAlchemy will rollback because there was no activity within it's scope. It sounds like you're trying to do the opposite of what the `transaction` package is designed to do. The way I normally deal with situations like that is to control if SQLAlchemy joins the transaction or not. In most projects, I only use the transaction on specific views that require this type of integration - such as anything that sends an email (pyramid_mailer integrates with pyramid_tm). It also sounds like your concern is mostly in testing. The approach I've started to standardize on is to have a database snapshot for tests and just recreate the database from that on every run. If you just want to completely disable database commits though, you could have your test harness set up a SQLAlchemy event listener for "commit", and then issue a "rollback" within the event. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/771e180a-ca5b-4625-baf7-972d237ea45an%40googlegroups.com.