Hi all, A very interesting discussion thread!
> > thats my own opinion , there is nothing wrong with SQLALCHEMY but I don't > quite understand whats going on internally so I stopped. > This might be a bit off-topic, but this is the weak area of SqlAlchemy. It is very brilliant engineering, but it is a very complex beast. Due to the legacy of Python documentation practices, its own documentation of reference manual is not as good as some others (e.g. Django) making SQLAlchemy harder to learn. Nowadays I program SQLAlchemy by using StackOverflow. This is after 10 years of using SQLAlchemy. Makes the process more tolerable. However, the extra power you get from it in a big project is worth it. The project needs to be a big though, and fit nicely into the web app/CRUD style scope. Which brings me to the offtopic questions: what are the best alternatives of SQLAlchemy in Python today - something that could be a bit easier to approach and might work better for smaller projects? Myself, I am probably too old to start learning anything new, so I just use SQLAlchemy and then drop to raw SQL strings when I need to deal with something ORM cannot handle. Br, Mikko > > 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 mmer...@gmail.com 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 <jvan...@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-discus...@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/ecd4876e-25e0-4676-92f5-b16fd7318bban%40googlegroups.com > <https://groups.google.com/d/msgid/pylons-discuss/ecd4876e-25e0-4676-92f5-b16fd7318bban%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAK8RCUspadzs9Z4w8u%3DtqPEsbV8x2H8%3DuLe7m6HoUuZ8GzBd%2Bg%40mail.gmail.com.
