On 10/27/05, Jeff Watkins <[EMAIL PROTECTED]> wrote: > On 26 Oct, 2005, at 11:42 pm, Kevin Dangoor wrote: > > > But if you don't even require a valid user, do you need to bring the > > User object into memory? > > Well the filter doesn't know whether code that executes later will > require the user object. It's possible the user object could be > lazily instantiated, but I think caching is probably a better answer.
Since the identity code is part of the framework, we can likely come up with a way for it to know. (For example, what if identity.require did the lookup? Of course, that doesn't take care of the case where you've configured access or set up permissions on a whole object...) > > So, if the cookie contained the ID of the user object (securely > > signed, of course), you could do a User.get() and save a query. > > Interesting. The cookie currently stores the user ID used to > authenticate not the magic number used to uniquely identify the > database row. I suspect this is one of those cases where using a non- > integer primary key might be beneficial. > > I'm not certain I like the idea of requiring that the > IdentityProvider translate the incoming user ID into a database row > ID. That just seems prone to confusion. This would only be the built-in SQLObject-based provider. Someday soon, I'll take a closer look at this so I can make more intelligible suggestions... I'm just tossing out generalizations based on high-level knowledge of the implementation. > Obviously, I'll need to think about this some more. Although it's a > shame that columns marked as alternateID=True don't cache correctly > when retrieved using the byAlternateID() accessor. Hmm... that sounds like a good suggestion for SQLObject. AFAIK, it doesn't cache byAlternateID. Kevin
