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
ourceip=source, timecreated=updtime, timesent
= None)
)
sess.execute(instmt)
* sess.commit()*
It now works like a charm.
Many thanks for the prompt and thoughtful replies.
On Wednesday, June 28, 2017 at 1:16:52 PM UTC-6, Richard Rosenberg wrote:
>
>
> Hello:
>
> I'v
h 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, Jun 28, 2017 at 3:43 PM, Jonathan Vanasco <jona...@findmeon.com
> >
fine, but upsert is the
right thing to do here.
I'll give begin_nested a try and post back.
Thanks again,
Richard
On Wednesday, June 28, 2017 at 1:43:22 PM UTC-6, Jonathan Vanasco wrote:
>
>
>
>> On Wednesday, June 28, 2017 at 3:16:52 PM UTC-4, Richard Rosenberg wrote:
>>
&
: Connection reset by peer
2017-06-28 12:55:12.288 MDT [7842] richard@stemp LOG: could not receive
data from client: Connection reset by peer
On Wednesday, June 28, 2017 at 1:16:52 PM UTC-6, Richard Rosenberg wrote:
>
>
> Hello:
>
> I've run into a problem with SQLA's
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 =
I think at this point, the docs are simply making it worse for me. Is there
an example out there that is declarative and concise?
This is a really simple scenario involving a single header table, and
multiple (identical) detail tables, as in:
headertable
1. id int
2. namekey varchar
