On Sat, May 12, 2018 at 4:28 PM, Jonathan Vanasco <jonat...@findmeon.com> wrote: > > > On Saturday, May 12, 2018 at 9:49:34 AM UTC-4, Mike Bayer wrote: >> >> >> The former would be a bug. The latter, I'm not sure what you would expect >> it to do. Do you want the unloaded attributes to raise attribute error? Or >> did you want the get() to fully refresh what was not loaded (that is >> doable). > > > The latter. The closest thing I've been able to get the behavior I need > with is a separate session. > > This need came due to application growth over a long period. > > The application previously had two phases: > > * phase 1: lots of eagerloading and joinedloading > * phase 2: leverage get(), which hits items loaded in phase1 99% of the > time.
Trying to take what you've said directly (rather than my usual glossing over things that aren't making sense and just re-asking), I don't yet understand what you want to do when: Phase one is a query with lots of joinedload, and *also*, a load_only() (Is that right? your previous email shows a joinedload + load_only, this email OTOH says "phase 1, lots of eagerloading and joinedloading", is that the one with the "load_only" ?) Then, you say, the get() in phase 2 (which we assume is the get() you refer towards in your previous email) hits objects from this joinedload + loadonly 99% of the time, so 1% of the time they are from a cache, which you haven't told me how objects get into that or what state they are in. And then you say, you don't like that when the program hits attributes on the object that came from the get(), they emit SQL. Instead, you'd like those attributes to be loaded already. Based on these facts, it seems like you would like to not use load_only in the first place, or, when you do the get(), you really would rather re-emit the query in all cases since 99% of these hits are already in the identity map and won't have the attributes you want. e.g. don't use get(), use query(..).filter_by(id=pk).first(). What I don't understand is what any of this has to do with the "phase 0" you refer towards so I am very uncertain that I'm understanding the problem. > > i just finished up some changes to the authorization system, which is now > using a dogpile cache with a small subset of keys on short timeout. when > there is a cache miss, this component executes sql before "phase 1" – i'll > call this "phase 0". > > a handful of items accessed in "phase 2" are now loaded into the identity > map during "phase 0", instead of being a miss. instead of saving a Sql > query, i'm now 20+ queries per object. > > > > > > > -- > 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 Example. See http://stackoverflow.com/help/mcve for a full > description. > --- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. -- 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 Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
