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.

Reply via email to