On Monday 16 July 2007 09:59:41 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? > > 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? i guess unless u are having another mixed-up-id's pseudo-concrete-inheritance case, it's okay. More, any object X inheriting C which inherits B which inherits A may get registered as all those (X,id), C(id), B(id), A(id) - as long as the id's are really same. But this is what _could_ be done, not what _should_ be done...
> On Jul 15, 11:47 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > > the "non polymorphic" search is against the Person mapper; it > > recieves id "1" and looks in the identity map for (Person, (1,)) > > and locates the existing object immediately. For id 2, it also > > looks in the map for (Person, (2,)), and finds nothing; it must > > issue a query which returns the fact that id 2 is of type > > "employee", creates the proper identity key of (Employee, (2,)), > > and returns the value from the identity map. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
