Scalable method for storing user's OpenID delegates [#308287]

If this module is used on a site with hundreds or thousands of users who all have OpenID delegates, those delegates are stored in the variables table and cached in the cache table, which is loaded on every page request. For every page request, this module loads the delegate URLs and other openidurl settings for all users. I can see this causing out of memory errors for large sites.

Do you agree? I can write a patch that moves these settings to a separate table.

Comment	File	Size	Author
#5	openidurl-user-data.patch	4.71 KB	Anonymous (not verified)

Comments

Comment #1

robloach

he/him

commented 15 September 2008 at 15:32

You're right, saving this data in the variables table is not good. Could it save the OpenID settings in the $user->data[] column?

Comment #2

Anonymous (not verified) commented 15 September 2008 at 21:45

You would know better than me how this might affect openid delegate queries. The user's profile is the URL where this information needs to be put into the page headers. The user is fully loaded from the database anyway when the profile URL is hit, so the delegate variables would be in easy reach.

Nobody ever needs to query the delegate URLs directly?

The sitewide openid delegate can continue to stay in variables table, yes?

Comment #3

christefano commented 10 November 2008 at 09:41

This is mostly just thinking out loud but what the heck. I'd love to see this solved by using profile fields created by the core Profile module.

It's an extra dependency but I think it would be an acceptable one. The profile fields could be created automatically when OpenID URL is enabled (the same way the vCard module does it).