Scalable method for storing user's OpenID delegates
bangpound - September 14, 2008 - 14:41
| Project: | OpenID URL |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
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.
#1
You're right, saving this data in the variables table is not good. Could it save the OpenID settings in the $user->data[] column?
#2
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?
#3
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).
#4
Still up for writing a patch, bangpound? :) At first sight, all you'd have to do is implement hook_user().
#5
Here's the patch to move openidurl data out of the variables table and into the user data field.
No upgrade path until we agree that this patch is acceptable. It's going to be tedious to migrate this data, I worry.
#6
#7
Thanks! Provides the update to remove the delegates from the variables table too.
#8
Automatically closed -- issue fixed for 2 weeks with no activity.