Thanks, that explains it. I was caching on the "before_flush" event, when the instances may not yet have existed in the database. I changed to "after_flush".
On Tuesday, January 14, 2014 6:58:38 PM UTC-5, Michael Bayer wrote: > > merging is usually what we recommend with caching, load=False is there to > ensure no more SQL is emitted. > > if the objects initially were persistent, and then cached, session.add() > would put them right back in as persistent, but then they need to not be > used in any other session, and they’d also conflict with any existing > identities. that’s why merge is preferred. But the error you’re getting > that the objects aren’t persistent is a little worrisome, though depends on > how you are getting at these objects in the first place. > > Basically “persistent” means inspect(my_object).key is present. that’s > the internal primary key that is assumed to have been used in the database. > if it’s empty/None, then it means the object doesn’t represent a row in > the DB. So an object that is cached and is presumed to represent a row in > the DB should typically have a non-empty .key on the internal state. > > > > On Jan 14, 2014, at 5:59 PM, [email protected] <javascript:> wrote: > > I resolved this by merging my cached instances into the session instead of > adding them. Does this have any negative side effects? It seems like the > right thing to do from the docs. Thanks Michael for your quick response. > > On Tuesday, January 14, 2014 5:48:55 PM UTC-5, Michael Bayer wrote: >> >> >> On Jan 14, 2014, at 5:44 PM, [email protected] wrote: >> >> I have discovered something interesting... >> >> (Pdb) db.session.refresh(fresh_profile) >> (Pdb) >> >> (Pdb) db.session.refresh(cache_profile) >> *** InvalidRequestError: Instance '<Profile at 0x1075e2b90>' is not >> persistent within this Session >> >> So the status of my cached instance is something other than persistent >> (is there a method to check this?). My theory is that relationship query >> won't fire because it believes it isn't yet saved to the db. >> >> >> http://docs.sqlalchemy.org/en/latest/orm/session.html#quickie-intro-to-object-states >> >> >> yes, inspect() will get you all that >> >> inspect(my_object).persistent >> >> >> http://docs.sqlalchemy.org/en/rel_0_9/orm/internals.html#sqlalchemy.orm.state.InstanceState.persistent >> >> >> >> >> >> On Tuesday, January 14, 2014 5:26:19 PM UTC-5, Michael Bayer wrote: >>> >>> >>> On Jan 14, 2014, at 4:36 PM, [email protected] wrote: >>> >>> > Help! >>> > >>> > I'm employing a cache strategy which saves Model instances to an >>> in-memory store. When I retrieve these instances from the cache, I add them >>> to my session. All the data is there, but when I try to use a relationship >>> property it returns None. >>> >>> “use”, like, my_instance.some_other_object returns None? What kind of >>> SQL output do you see when you hit that attribute? How is “my_instance” >>> being created in the first place? >>> >>> >>> > >>> > A test with two objects: cache_obj and fresh_obj, the only difference >>> I see is that one has a unicode string for it's foreign key and the other >>> does not (which is also strange). >>> > >>> > (Pdb) fresh_obj_map.attrs['profile'].target == >>> cache_obj_map.attrs['profile'] >>> > True >>> > >>> > (Pdb) cache_obj.profile_id >>> > '2cedffc2-7d5c-11e3-8cb0-c82a1412a8b6' >>> > >>> > (Pdb) fresh_obj.profile_id >>> > u'2cedffc2-7d5c-11e3-8cb0-c82a1412a8b6' >>> > >>> > (Pdb) cache_obj.profile >>> > >>> > (Pdb) fresh_obj.profile >>> > <alphaworks.models.profile.Profile object at 0x10215e910> >>> >>> if profile_id is a string column all the way then the u’’ ‘’ difference >>> shouldn’t be much of an issue. >>> >>> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/sqlalchemy. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
