On Monday 16 March 2009 6:44:14 pm Steve Yelvington wrote:
Awhile back I wrote a simple module to fetch my Facebook status line, using an open RSS feed, and make a block to display on my blog. The fetched data is stored in cache for a limited period. http://drupal.org/project/fbstatus
I've received a number of requests to upgrade the module to support multi-user scenarios. In such a case, cache obviously isn't the right place to put the data.
Why obviously? Cache is for non-persistent data that is expensive to generate or retrieve but that you want to have fast access to. Locally caching facebook data seems perfectly reasonable for that.
But since there should be no more than one Facebook account per user, it seemed that creating a table (as seen in the Twitter module) would be overkill.
Why? There are tons of modules that add one table per user or per node in order to extend those entities. That's the way modules are supposed to work. It's why hook_nodeapi op load and hook_user op load exist.
So I began looking at using profile fields (requiring profile.module) or the serialized user data.
Do not use $user->data. It's only kept around as a booby trap to break the brains of unsuspecting new developers with strange and obscure bugs they do not understand. Profile.module is not much better, and is hopefully slated for execution in Drupal 7.
But I'm likely to move the updates into hook_cron, and I can imagine a large site having to step through the whole user base, looking for statuses needing updates.
So now I'm back at a discrete table.
Is my thinking right?
Nothing wrong with a discrete table or the cache in this case. The main question is whether you want to lazy-fetch data on users (and therefore have an easy "rebuild all" command; just empty the appropriate cache table) and then not be able to query directly against the local data, or want to have to maintain your own data tables and handle synchronization of data but have persistent, easily-queried-against local tables you could even expose to Views. (Oooo...) Either way works. Off the cuff I'd probably go for the discrete table myself, but there are good arguments either way. -- Larry Garfield larry@garfieldtech.com