Mike,
We've upgraded to that latest and greatest SQLAlchemy, did some
instrumentation and confirmed we were getting bit in _fast_discard.
Thank you for your very prompt responses, we really appreciate your help.
Cecil Rock
On Mon, Feb 26, 2018 at 6:23 PM, Mike Bayer
wrote:
> On Mon
> On Mon, Feb 26, 2018 at 4:06 PM, Cecil Rock wrote:
> > OH, man sorry I misunderstood that issue. I have been starring at this
> for
> > too long :)
> >
> > Yes, that totally could be it. I'll apply that patch and should be able
> to
> > confir
OH, man sorry I misunderstood that issue. I have been starring at this for
too long :)
Yes, that totally could be it. I'll apply that patch and should be able to
confirm it or not.
On Mon, Feb 26, 2018 at 1:02 PM, Mike Bayer
wrote:
> On Mon, Feb 26, 2018 at 3:58 PM, Cecil Roc
. It is helpful to know
that a bug doesn't come to mind with this. I'll see if I can mess with the
GC and run that to ground or not. If you have any other ideas they are
much appreciated :)
On Mon, Feb 26, 2018 at 12:46 PM, Mike Bayer
wrote:
> On Mon, Feb 26, 2018 at 3:33 PM,
ng without
understanding could just mask the issue if it exists.
On Monday, February 26, 2018 at 12:28:49 PM UTC-8, Mike Bayer wrote:
>
> um what version of SQLAlchemy is this?
>
> On Mon, Feb 26, 2018 at 3:22 PM, Cecil Rock > wrote:
> > One of my thoughts was maybe the gc wi
One of my thoughts was maybe the gc wiped out the identity_map and it gets
recreated empty.
Here is a stack trace of when I detect the situation prior to the flush
occurring.
[4018/eval_0/INFO/state/554/_modified_event] fc3a3a adding state.InstanceState object at 0x7f6a5bb989e8> as modified in
Hi,
I have a question about some ORM internal state tracking stuff. If this
isn't the right venue for this type of question my apologies.
I've run into what looks like a race condition using the ORM during some
our production workloads. I am trying to figure out if our code has a bug
or if
