On Monday 16 July 2007 17:08:08 Michael Bayer wrote:
> 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).

i think it is not a problem to store as many keys as there are 
identical levels in polymorphism/inheritance as long as this is 
synchronized with type of inheritance.
i.e. joined-table inheritance chains (and single table maybe) are ok 
as is, anything concrete-table in between changes the game.
As for the concrete, i think it can be done same as with 
polymorphism - storing composite keys (type,id) where just keys are 
ambigious.

but i bet noone has ever wanted mixed inheritance, no? (:-)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to