Re: [pylons-discuss] Relationship between requests and Zope transactions

> > Added yet another one or two parameters (sigh) to functions, but it keeps > things functional and without outside (global, thread-local) state. This is where something like pyramid_services [1] really excels. It'll drastically cut down on concerns like that when you adopt some form of inversi

Re: [pylons-discuss] Relationship between requests and Zope transactions

functools.partal might help in some cases. On Fri, Sep 7, 2018 at 1:44 AM wrote: > > Thank you Mike for the information, that all makes sense. I ended up with the > same approach that SQLA takes: a “Session” object owned by a DataManager, > joined to the Request’s TransactionManager. And then ju

Re: [pylons-discuss] Relationship between requests and Zope transactions

Thank you Mike for the information, that all makes sense. I ended up with the same approach that SQLA takes: a “Session” object owned by a DataManager, joined to the Request’s TransactionManager. And then just pass a `dbsession` and `fnsession` and `jobsession` around to functions as needed. A

Re: [pylons-discuss] Relationship between requests and Zope transactions

+1 on being explicit by passing around the request (or something similar). there are way too many edge cases when you try to compute the current request/transaction, and it's incredibly hard (a nightmare) to write tests that work correctly when you rely on the derived/computed methods. -- You

Re: [pylons-discuss] Relationship between requests and Zope transactions

On Sun, Sep 2, 2018 at 7:31 AM wrote: > If requests during their life cycle would derive from threading.local and > initialize such a storage area upon construction (e.g. after tween ingress) > and tear it down (e.g. after tween egress) then deeply nested function could > still access a request

Re: [pylons-discuss] Relationship between requests and Zope transactions

> > You are talking about these two lines of code > > in > the cookiecutter’s model/__init__.py, c

Re: [pylons-discuss] Relationship between requests and Zope transactions

Maybe some background… the reason why I asked the initial question is because a few (and a growing number of) request handlers are complex; that is, they call multiple function levels deep. Now request.dbsession, for example, is SQLA’s current DB session tied to the request’s transaction. To ge

Re: [pylons-discuss] Relationship between requests and Zope transactions

Maybe some background… the reason why I asked the initial question is because a few (and a growing number of) request handlers are complex; that is, they call multiple function levels deep. Now request.dbsession, for example, is SQLA’s current DB session tied to the request’s transaction. To ge

Re: [pylons-discuss] Relationship between requests and Zope transactions

Thanks Michael! You are talking about these two lines of code in the cookiecutter’s model/__ini

Re: [pylons-discuss] Relationship between requests and Zope transactions

Jens, by default your example is true, but it is not true in the cookiecutter configuration. The value of request.tm is defined by the tm.manager_hook setting and by default it is the threadlocal transaction.manager. The cookiecutter overrides the hook (and I suggest you do as well) to define a non

[pylons-discuss] Relationship between requests and Zope transactions

Hi, According to the documentation here , “Pyramid requests [to] join the active transaction