On Jul 16, 2007, at 2:59 AM, Yves-Eric wrote:
> > Thanks for the explanation! The root of the issue is now very clear. > But are you saying that this is intended behavior? Was I wrong in > trying to use the session as an object cache? this is why im extremely hesitant to call the session a "cache". its only slightly cachelike becuase in most cases it doesnt prevent SQL from being issued. > > Now onto a possible solution or workaround... Please forgive me if the > following does not make sense, but would it be possible to store our > object in the identity map under a second key: (Person, (2,))? Then > the Person mapper would find it and we'd avoid having to generate a DB > query. Is there any technical issue that would prevent the same object > from being registered under different keys in the identity map? There are some kinds of inheritance where both Person/2 and Employee/ 2 exist distinctly, namely the concrete inheritance svil mentions. so that makes me less comfortable with that approach. it does seem like you can in many cases define the set of identities for an entire class hierarchy a/b/c/d/e... against the root mapper only, i.e. just (A, (id,)). its something to look into (changing the key to represent based on the root class in all non-concrete cases, not storing two keys). if you were so inclined you could also add this you can build this yourself and wire it in to query.get() using a MapperExtension that implements get() (and populates the cache during populate_instance(), perhaps...we will have a better hook for "post-load" operations in 0.4). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
