I think it's worth noting that zope.sqlalchemy's session registration supports a "readonly" initial state, similar to active and changed that we've all harped on in the past. I'd probably just look into using that and sticking with existing patterns. If you go all-in on readonly as a pattern I think it could be a lot simpler but hey, this lets you use the existing pattern.
On Wed, Aug 17, 2022 at 1:26 PM Jonathan Vanasco <jvana...@gmail.com> wrote: > If it's read-only, i would not have it join the transaction and just > create the cleanup subscriber in the @reify . > > > # Because this was in the tutorial. > > I believe that is in there because of me. This pattern is used to provide > access to the current request within SqlAlchemy objects and various > @property or @reify decorated methods. Without it, you must explicitly > pass in a request (so no decorators) or use the `get_current_request` > function which should generally be avoided. There is a bit of discussion > on it in the PR, and the cookiecutter template has many notes on it. See > https://github.com/Pylons/pyramid-cookiecutter-starter/pull/111 > > On Tuesday, August 16, 2022 at 5:50:02 PM UTC-4 Mike Orr wrote: > >> 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 >> <pylons-...@googlegroups.com> 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 pylons-discus...@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. >> >> >> >> >> -- >> Mike Orr <slugg...@gmail.com> >> > -- > 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/afd190a0-8b0e-412d-bd52-1ccdfe403994n%40googlegroups.com > <https://groups.google.com/d/msgid/pylons-discuss/afd190a0-8b0e-412d-bd52-1ccdfe403994n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Michael -- 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/CAKdhhwF2R5HxWU-dUQ0se%2Bj%2BVD89PRc2xbv_Y%2BkgHb1mCLhQFg%40mail.gmail.com.
