The SQLite database is pregenerated for a release and contains only
reference information. It's read only to the web application. So I'm
wondering if it's worth even hooking the session into the transaction
manager at all. I have a request subclass, and to open a session I use
a reified method:
@reify
def sa_session(self):
engine = self.registry.sa_engine # Attribute set during startup
configuration.
info = {"request": self} # Because this was in the tutorial.
sess = sqlalchemy.orm.Session(engine, info=info)
zope.sqlalchemy.register(sess) # Is this worth doing for a
read-only database?
return sess
The transaction manager closes the session for me, so without it I
guess I'd have to have a subscriber that rolls back and closes the
request. I don't want to have to do it in every view because it's not
view-specific logic.
On Tue, Aug 16, 2022 at 9:19 AM 'Jonathan Vanasco' via pylons-discuss
<[email protected]> wrote:
>
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/771e180a-ca5b-4625-baf7-972d237ea45an%40googlegroups.com.
--
Mike Orr <[email protected]>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3Duq9HZVsyVJir4QzG0v8AXs-MURjxNAZ6uqH2LPkdiEW1A%40mail.gmail.com.
