Oh, nifty. And good docstring. I'd just say though that if you need the request and don't have it, it's often an indication that the program's structure is wrong. Although there are certainly times when you need something like this, such as when you call a third-party function that doesn't take a request, then it calls you and you need the request but the caller hasn't passed it through.
On Sat, Feb 20, 2021 at 3:42 PM Michael Merickel <mmeri...@gmail.com> wrote: > > It's in the cookiecutter's "get_tm_session" on the master branch. Which is > not the default branch. > > The purpose of the pattern is if your model objects needed access to some > settings or some other request properties. It's up to you to decide if that's > good or bad. Of course you don't need to use it. > > - Michael > > > On Feb 20, 2021, at 17:39, Mike Orr <sluggos...@gmail.com> wrote: > > > > On Sat, Feb 20, 2021 at 12:57 PM Michael Merickel <mmeri...@gmail.com> > > wrote: > >> Check out the new pattern of storing the request in the SQLAlchemy session > >> object for easier access in your model layer without threadlocals! > > > > Where is that? I don't see it in 'pyramid-cookiecutter-starter' or the 2.0 > > docs. > > > > I do essentially the opposite. I have a request subclass with reified > > methods for external resources like 'request.sa_session()'. > > Cookiecutter is still using this concept although using > > 'config.add_request_method()' instead of a subclass: > > > > https://github.com/Pylons/pyramid-cookiecutter-starter/blob/latest/%7B%7Bcookiecutter.repo_name%7D%7D/%7B%7Bcookiecutter.repo_name%7D%7D/sqlalchemy_models/__init__.py > > (Lines 71-75.) > > > > My model classes used to have querying methods but I moved away from > > that because they ended up putting too much into the models and being > > too limiting (my querying needs inevitably expanded beyond the method > > arguments). I now have just the columns and relations in the models, > > and separate lib modules for high-level queries. These take a session > > argument. I don't usually need a request argument except occasionally > > for URL generation. For that I have a postprocessing function that > > adds the URL attributes to the query results. For instance: > > > > # View > > results = myapp.lib.mysearch.do_search(sa_session, ...criteria..) > > # Return list of ORM objects, > > postprocess(results, request) > > # Iterate through objects, adding URL attributes for HTML links, > > # formatting dates, calculating display values, etc. > > > > -- > > 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/CAH9f%3Duo821nzLFSttTcvn5xBqbAL2hisuQWUE_%2BCS8q15zUgRA%40mail.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/AE3A3A43-AECE-49D5-BB83-AAC8A3DC0798%40gmail.com. -- Mike Orr <sluggos...@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/CAH9f%3DupXuDF4-nwOhOnxNpSV_rrEkADF0KxbFONx0XotpeW1WQ%40mail.gmail.com.
