I understand your concerns. I dropped pyramid's transaction support a long
time ago, and prefer to do everything explicitly.
You should be aware that a scoped session and regular session are not 100%
interchangeable. There are a few slight differences... though 99.9% of
users won't be
Jonathan:
Yeah. That seems likely.
However, I feel "closer" to my database after removing zope.sqlalchemy from
the mix. I guess I'm at a point where there is such a thing as too much
abstraction. . ?
BTW, I did give the nested tx a try, but as we both now know it did not
work, and probably
This turned out to be pleasantly painless. Posted here for the sake of "the
next guy."
First, I removed all of the import transaction statements.
Next, I changed the models.__init__:
def get_tm_session(session_factory, transaction_manager):
"""
Get a ``sqlalchemy.orm.Session`` instance
On Wednesday, June 28, 2017 at 4:28:32 PM UTC-4, Mike Bayer wrote:
>
> I'm not 100% sure that zope.sqlalchemy unconditionally emits COMMIT
> for the session that's associated. Though overall would need to see
> where you're getting request.session from and all that; if it's not
> associated
Mike:
Thanks for your reply.
This is a stock pyramid app built with their SQLA "scaffold." As expected,
any attempt to directly use commit on the session results in:
File
"/home/richard/vp36/lib/python3.6/site-packages/zope.sqlalchemy-0.7.7-py3.6.egg/zope/sqlalchemy/datamanager.py",
line
Jonathan:
Thanks for your reply. After perusing the link you provided, I'll give
begin_nested a try.
And you're quite right, its probably not pyramid_tm so much as the
zope.sqlalchemy. But truthfully, I don't know why it is happening. The
prior bulk insert pattern using sess.add_all worked
I'm not 100% sure that zope.sqlalchemy unconditionally emits COMMIT
for the session that's associated. Though overall would need to see
where you're getting request.session from and all that; if it's not
associated with zope.sqlalchemy then you'd need to call
session.commit() explicitly.
On Wed,
> On Wednesday, June 28, 2017 at 3:16:52 PM UTC-4, Richard Rosenberg wrote:
>
On Wednesday, June 28, 2017 at 3:16:52 PM UTC-4, Richard Rosenberg wrote:
>
>
> I am absolutely puzzled, but it seems likely that pyramid_tm is in the way
> somehow. It always wants to do its own thing, and calling
Oops. . .wrong log entries for the postgres log. They should look like this:
2017-06-28 12:02:39.547 MDT [4456] richard@stemp LOG: could not receive
data from client: Connection reset by peer
2017-06-28 12:02:39.548 MDT [4456] richard@stemp LOG: unexpected EOF on
client connection with an
