my only concern is that you now have "more than one way to do it". i need to deal with things in the identity map. do i go look at the session.identity_map ? (which is documented, its part of the public API) oh no, i dont have the exact kind of key to use, now i have to go use a method called "find()" (which again, does that mean, find it in the database ? where is it looking ?)
the identity_map accessor on Session is pretty much only used by the public API so yes we'd make a wrapper around the underlying dictionary/ weak dictionary. i think its more pythonic to use property-style access rather than methods (which in javaland feels very dangerous...but in python, its not ! really ! heres the article that convinced me http://dirtsimple.org/2004/12/python-is-not-java.html ). On Mar 8, 8:13 pm, Daniel Miller <[EMAIL PROTECTED]> wrote: > Michael Bayer wrote: > > fine, but the name "get_local" is not so descriptive and also attracts > > the focus away from the existing "identity_map" accessor. how about > > we jack up the "identity_map" dictionary to be smarter ? so you could > > say: > > > session.identity_map.find(class_, ident, entity_name='foo') > > Are you going to make the identity_map a subclass of dict then? What about > the weak_identity_map option--will there be a subclass of > weakref.WeakValueDictionary too? That smells a bit. I guess the right way to > do it is to make a wrapper around the "real" identity_map, but then you're > starting to add more overhead to accessing the identity_map... Your > suggestion is fine from a functional point of view, it just seems to add more > complexity than it's worth (i.e. it would require an entire subclass (or two) > or a wrapper instead of just a single function). > > The identity_map has always seemed like more of an implementation detail than > an exposed part of the session interface (to me at least). The Session class > is a facade to the UnitOfWork/identity_map. When I start to write code that > depends heavily on those inner parts of the session I feel a bit > nervous--like I'm writing fragile code. > > The other thing is documenting this in a way that people will be able to > easily find it. The first place I would go to look for a feature like this is > on the session--identity_map has always had the semantics of a plain dict. > Would it be OK to name it session.find() and clearly document it's behavior > with the other similar functions like session.get() and session.load()? The > only possible issue is that it definitely does does NOT belong on Query > unlike get() and load(). I expect it will be used more with expire() and > expunge() so maybe that doesn't matter since neither of those methods are > part of the query interface either. I don't really care, I'm just giving the > first thoughts that come to mind here. > > ~ Daniel > > > > > On Mar 8, 10:07 am, "Daniel" <[EMAIL PROTECTED]> wrote: > >> Could we add this new method on sqlalchemy.orm.Session? > > >> def get_local(self, class_, ident, entity_name=None): > >> """Get an object from the identity map (do not hit the database) > > >> Returns None if the object does not exist in this session's > >> identity map. > >> """ > >> idkey = self.mapper(class_, > >> entity_name=entity_name).identity_key(ident) > >> return self.identity_map.get(idkey) > > >> This is handy for doing tasks such as expiring/expunging/etc. an > >> instance but only if it exists in the session. I'm not sure if it > >> makes sense to have the entity_name parameter because I've never used > >> it before, but I added it just in case. > > >> Thanks, > >> ~ Daniel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
