Pyramid 2.0b1 released

[Michael Merickel]

Pyramid 2.0b1 has been released.

- Fixes a circular reference / memory leak between request and context in some apps.

- A bunch of documentation and cookiecutter improvements. Check out the new pattern of storing the request in the SQLAlchemy session object for easier access in your model layer without threadlocals!

This is the last release prior to 2.0 which will probably come next weekend.

The full changelog is here:
https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/changes.html

What's New In Pyramid 2.0:
https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/whatsnew-2.0.html

2.0 release documentation (across all alphas and betas, as well as when it gets to final release):
https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/

You can install it via PyPI:

pip install Pyramid==2.0b1

Enjoy, and please report any issues you find to the issue tracker at
https://github.com/Pylons/pyramid/issues

Thanks!

- Pyramid core developers

[Mike Orr]

On Sat, Feb 20, 2021 at 12:57 PM Michael Merickel <mmer...@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.

[Michael Merickel]

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

> --
> 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/CAH9f%3Duo821nzLFSttTcvn5xBqbAL2hisuQWUE_%2BCS8q15zUgRA%40mail.gmail.com.

[Mike Orr]

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.

> 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 <slugg...@gmail.com>

[Jonathan Vanasco]

> 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.

I authored this change, and you are absolutely correct.  This technique is not ideal, but it is designed to stop several anti-patterns that happen with great frequency in many SQLAlchemy web integrations in a "less evil" but "supported" pattern.

A lot of web implementations will use global variables to access the active web request when dealing with "Model" concepts  (examples include Flask-SQLAlchemy and legacy Pylons) which is an anti-pattern; a lot of Pyramid applications used `get_current_request`, which is explicitly warned against.  

In this technique, the "info" dict - which is the official SQLAlchemy place for end-users to place data into a session - is used to stash the request.  It's a bit odd -- the request has a session which has the request - but it's the safest way to make the request available to any SQLAlchemy object.  (note: this breaks once the session is closed or the object leaves the session)  This also makes testing much, much, much easier.

Models shouldn't need to be aware of the context, but sometimes it's the best option.  I specifically wrote it so people can  get to the `request.registry` to access application settings, like Michael mentioned.  

FWIW, my preferred technique is to structure a SQLAlchemy model independent of Pyramid (either as a separate package or part of a larger package at the same "level" as the Pyramid app), and have Pyramid/Celery/Commandline-tools etc import that model.  Each framework then notes in the "info" dict (i) which system SQLAlchemy is being run under and (ii) the current request or context. For the sake of simplicity, I left that stuff out of the PR.