Re: [sqlalchemy] Event listener for when query results get matched with pre-existing objects on the session

t 20, 2023, at 10:46 AM, 'Tony Cosentini' via sqlalchemy wrote: > > Oh I see, thanks for clarifying. > > I'm trying to detect cases where we depend on the autoflush behavior. For > example, in the sample above, when the query runs with no_autoflush, we > won'

Re: [sqlalchemy] Event listener for when query results get matched with pre-existing objects on the session

so I was trying to automate finding these cases in order to add explicit flush calls when needed or just pass in the pending object instead of running a query. Tony On Fri, Oct 20, 2023 at 10:42 PM Mike Bayer < mike_not_on_goo...@zzzcomputing.com> wrote: > > > On Fri, Oct 20, 202

Re: [sqlalchemy] Event listener for when query results get matched with pre-existing objects on the session

ke_not_on_goo...@zzzcomputing.com> wrote: > > > On Fri, Oct 20, 2023, at 8:08 AM, 'Tony Cosentini' via sqlalchemy wrote: > > Hi, > > Is there any way to listen for an event for when a query result gets > merged into a pre-existing object in the session? > > > this

[sqlalchemy] Event listener for when query results get matched with pre-existing objects on the session

Hi, Is there any way to listen for an event for when a query result gets merged into a pre-existing object in the session? I'm working on disabling autoflush for some of our codebase (mostly to cut down on queries on a high QPS path), but before doing that I want to write a utility to detect w

Re: [sqlalchemy] DRYing up model relationships with custom properties

pper so that you can apply > things after the fact, a good event for this would be "instrument_class": > https://docs.sqlalchemy.org/en/20/orm/events.html#sqlalchemy.orm.MapperEvents.instrument_class > > > On Wed, May 3, 2023, at 4:18 AM, 'Tony Cosentini' vi

[sqlalchemy] DRYing up model relationships with custom properties

Hi, I have a pattern in some models where there is a private (as in prefixed with __) relationship and then a property to handle some things that need to happen when the relationship is fetched or written to. Currently it's implemented like this: class ModelClass(Base): __field_for_relationsh

Re: [sqlalchemy] Re: load_only when loading relatinoships from an instance

try adding > session.expunge_all() before the query and see if that makes things look > more expected. > > On Thu, Jan 5, 2023, at 1:27 AM, 'Tony Cosentini' via sqlalchemy wrote: > > Ok, I was able to at least create a script that easily reproduces what I'm >

[sqlalchemy] Re: load_only when loading relatinoships from an instance

It sounds bizarre, but that gist link contains a really short sample that reproduces the same behavior. I'm running 1.4.44. Tony On Thursday, January 5, 2023 at 11:09:40 AM UTC+8 Tony Cosentini wrote: > Funny enough, this is what I tried. I just wrote up a small sample script &

[sqlalchemy] Re: load_only when loading relatinoships from an instance

Funny enough, this is what I tried. I just wrote up a small sample script using defaultload + load_only and sure enough it works. There must be something in the code base I'm working with that prevents the load_only bit from being applied. I'm pretty sure defaultload is woroking fine. I'll repo

[sqlalchemy] load_only when loading relatinoships from an instance

Hi, This might be a strange question, but I tried to find this in the documentation to no avail. Is it possible to use something like load_only to override which columns are loaded in when loading a relationship (as in, a relationship that is not loaded at first with the original query)? Some

Re: [sqlalchemy] Large increase in memory use when upgrading from 1.3 to 1.4

do :). Thanks again for helping look into this, Tony On Monday, November 14, 2022 at 3:43:53 PM UTC+8 Tony Cosentini wrote: > Oh wow, this sounds like it would definitely impact us. I'm out this week > travelling, but I will definitely upgrade + re-enable the cache and report &g

Re: [sqlalchemy] Large increase in memory use when upgrading from 1.3 to 1.4

m/sqlalchemy/sqlalchemy/issues/8790. > > On Thu, Nov 3, 2022, at 8:33 AM, Mike Bayer wrote: > > > > On Thu, Nov 3, 2022, at 3:11 AM, 'Tony Cosentini' via sqlalchemy wrote: > > Hey, sorry for the crazy delay on this! > > We ended up turning off the cache i

Re: [sqlalchemy] Large increase in memory use when upgrading from 1.3 to 1.4

nyone else that runs into these kinds of issues. Thanks again Mike for the helpful response! Tony On Friday, October 21, 2022 at 8:08:32 PM UTC+8 Tony Cosentini wrote: > Hi Mike, > > Thanks for such a fast reply! We tried setting query_cache_size on a > canary environment today,

Re: [sqlalchemy] Large increase in memory use when upgrading from 1.3 to 1.4

ne is more of a theory though). I'll report back if we see any changes. Thanks again for the fast reply (and for building such a useful + well documented library), Tony On Friday, October 21, 2022 at 12:20:07 PM UTC+8 Mike Bayer wrote: > > > On Fri, Oct 21, 2022, at 12:00

[sqlalchemy] Large increase in memory use when upgrading from 1.3 to 1.4

Hi, We recently upgraded our application (a Flask web app) from SQLAlchemy 1.3.19 to 1.4.41. Overall things are stable, but we have noticed a very large increase in memory use: [image: Screen Shot 2022-10-21 at 11.26.18 AM.png] Is this from the new query caching feature? I'm planning on gettin

Re: [sqlalchemy] Ocassional Gevent BlockingSwitchOutError crashes when using pool_recycle

t; > I think overall the issue is that you have a _finalize_fairy with a > rollback happening at all. I could see that happening if you had a > greenlet interrupted but otherwise we would assume your code gracefully > closes all Sessions / Connections . > > On Wed, Jun 3, 2020, at

[sqlalchemy] Ocassional Gevent BlockingSwitchOutError crashes when using pool_recycle

Hi all, Apologies for the long-winded question. I'm currently working on an application that uses SQLAlchemy along with gevent + psycogreen + gunicorn. I recently added a pool_recycle of 120 to one of our engines: engine = create_engine( db_url, pool_size=default_manager.database_pool_si