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

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't get back any results (w

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

ner set to just crash, but it never triggers. > > On Fri, Oct 20, 2023 at 9:20 PM Mike Bayer < > mike_not_on_goo...@zzzcomputing.com> wrote: > > > > > On Fri, Oct 20, 2023, at 8:08 AM, 'Tony Cosentini' via sqlalchemy wrote: > > Hi, > >

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

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 is the refresh even

[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

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

per 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' via sqlalchemy wr

[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):

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

ing > 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 > seeing - > https://gist.gi

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

Ok, I was able to at least create a script that easily reproduces what I'm seeing - https://gist.github.com/tonycosentini/22f42455c5068898efa473760e4f65ed We have some code that runs before our tests to ensure all the tables are empty. When that runs, load_only doesn't seem to work. It sounds

[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

[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)?

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

bility >> to test ahead of time to see if it resolves your issues, let me know. I am >> attempting to improve upon the patch to reduce memory use further. issue >> is tracked at https://github.com/sqlalchemy/sqlalchemy/issues/8790. >> >> On Thu, Nov 3, 2022, at

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

lchemy/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 in everything via que

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

k 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 AM, 'Tony Cosentini' v

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

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 AM, 'Tony Cosen

[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