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.
SQLObject is likely caching the object, but it does not (AFAIK) cache
SelectResults.
[...]
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.
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.
--
Jeff Watkins
http://metrocat.org/
'I know about people who talk about suffering for the common good.
It's never bloody them! When you hear a man shouting "Forward, brave
comrades!" you'll see he's the one behind the bloody big rock and the
one wearing the only really arrow-proof helmet!'
-- Rincewind gives a speech on politics. (Terry Pratchett,
Interesting Times)
