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
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
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
> 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
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 =
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
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,
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
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
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
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
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
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).
>
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.
>
>
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?
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
16 matches
Mail list logo