Ok, so we had a retry decorator around a group of ORM calls. This seems to
be the issue. If we wrap each call instead, things are much better.
I wonder if the transaction rollback is causing issues.
Karim
On Monday, 2 March 2020 10:28:41 UTC-8, Karim Gillani wrote:
>
> Sadly we are still
That's an interesting point. I actually pull it in as an imported class
using
@as_declarative()
class MyClass
Forcing an import reload for each initialization made all the difference.
Thanks for your help.
On Monday, March 9, 2020 at 4:19:31 PM UTC-7, Mike Bayer wrote:
>
>
>
> On Mon, Mar 9,
On Mon, Mar 9, 2020, at 5:40 PM, Don Smiley wrote:
> In unit testing with multiple configurations, I am having trouble closing out
> everything to go on to the next iteration. For example, the test creates a
> class Address. I get the following kind of error:
>
> ```
>
In unit testing with multiple configurations, I am having trouble closing
out everything to go on to the next iteration. For example, the test
creates a class Address. I get the following kind of error:
```
Thanks Jonathan. This is a very low traffic application, so not a problem
but I appreciate you mentioning it.
--
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
FWIW: If your application is high-traffic/high-concurrency, depending on
how your transactions are scoped within the code you may want to do the
getcreate or create step that calls `.flush` within an exception block or
savepoint, to catch duplicate inserts.
I've only had to do this on 2 (out
