I would like to thank you for taking the time to reply and simplify things.
yes I would like to go lower / close to metal because there is a lot of postgresql API that I would like to access and experiment with. I don't want to fight with any abstraction layer and development time is really not an issue since this tool is used only by me. so I am not under any pressure to iterate quickly or push out a new feature to meet any demand. I remember a few years ago taking almost a day to modify a model to return json, it was so simple but it took me a day and I wasn't really sure of the internals so i was worried that It will take me months to understand SQLALCHEMY way of doing things , while what I was doing shouldn't take even half hour to accomplish. thats my own opinion , there is nothing wrong with SQLALCHEMY but I don't quite understand whats going on internally so I stopped. the more I look into postgres the more I want to make a use of it is features. On Wednesday, August 17, 2022 at 9:46:06 PM UTC+3 [email protected] wrote: > 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 <[email protected]> > 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 >>> <[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/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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/ecd4876e-25e0-4676-92f5-b16fd7318bban%40googlegroups.com.
