[sqlalchemy] Re: SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Richard Rosenberg
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

Re: [sqlalchemy] Re: SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Jonathan Vanasco
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

Re: [sqlalchemy] execute Stored procedure.

2017-06-28 Thread Mike Bayer
On Wed, Jun 28, 2017 at 4:21 AM, Simon King wrote: > On Wed, Jun 28, 2017 at 6:39 AM, Vigneshrajan wrote: >> Is it is possible to execute stored procedure in connection.execute() >> function? >> > > I think it depends on the stored procedure. Do any

[sqlalchemy] Re: SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Jonathan Vanasco
> 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

[sqlalchemy] SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Richard Rosenberg
Hello: I've run into a problem with SQLA's implementation of postgresql's upsert. The equivalent statement works fine when run as a straight up query (thru pgadmin). The model(s) in question: class TileUpd(Base): __tablename__ = 'tile_upd' __table_args__ = TARGS hostname =

[sqlalchemy] Re: SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Richard Rosenberg
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

Re: [sqlalchemy] Re: SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Mike Bayer
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,

Re: [sqlalchemy] Re: SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Richard Rosenberg
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

[sqlalchemy] Re: SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Richard Rosenberg
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

Re: [sqlalchemy] Re: SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Richard Rosenberg
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

Re: [sqlalchemy] Re: SQLA pg upsert causes impl rollback, works thru CL query

2017-06-28 Thread Jonathan Vanasco
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

Re: [sqlalchemy] Re: Wierdness with JSONB / Python dictionary

2017-06-28 Thread Andrew M
It helps a great deal, thank you Simon. Thanks for taking the time to explain it for me. -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See

Re: [sqlalchemy] Trouble with ordering_list extension

2017-06-28 Thread Mike Bayer
On Wed, Jun 28, 2017 at 12:02 AM, Andy Green wrote: > Now, some investigating has revealed the following information: > - commenting out the `__reduce__` function on OrderedList seems to make > everything work correctly (including the unit tests on orderinglist.py). >

Re: [sqlalchemy] require explicit FROMs

2017-06-28 Thread Mike Bayer
On Mon, Jun 26, 2017 at 2:24 PM, Dave Vitek wrote: > In case anyone tries to use the compile visitor below, I'll document a > couple snags I ran into. For now, I think I'm satisfied to go back to my > original patch and deal with any merge conflicts during upgrades. > >

Re: [sqlalchemy] execute Stored procedure.

2017-06-28 Thread Simon King
On Wed, Jun 28, 2017 at 6:39 AM, Vigneshrajan wrote: > Is it is possible to execute stored procedure in connection.execute() > function? > I think it depends on the stored procedure. Do any of these search results help?

Re: [sqlalchemy] Re: Wierdness with JSONB / Python dictionary

2017-06-28 Thread Simon King
On Wed, Jun 28, 2017 at 1:35 AM, Andrew M wrote: > I can also replicate it with JSON, with a table defined as follows: > > class Test(Base): > __tablename__ = 'test' > id = Column(INT, primary_key=True, index=True) > json = Column(JSON, default={}) > > And