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. 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. So I began looking at using profile fields (requiring profile.module) or the serialized user data. 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?
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
There is nothing wrong with cache, as Crell said. I have done both techniques. However, one caveat with cache - it is not as persistent as one would like to think. There are many events that cause it to be cleared. Using a minimum lifetime also interferes with some very popular (i.e. core) modules. I have to agree with Crell's conclusion, go with a discreet table if your data needs to be consistently persistent. So let me add a bit to the question because I just came across it in a contrib. Let's say you need one field that exactly matches a core table. Is it ever okay, upgrades aside, to add that column to the core table? Some things I've read about D7 seem to indicate this will be okay in D7. The use of "drupal_write_record" really makes this a convenient practice. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.11.15/2003 - Release Date: 3/15/2009 2:07 PM
So let me add a bit to the question because I just came across it in a contrib. Let's say you need one field that exactly matches a core table. Is it ever okay, upgrades aside, to add that column to the core table? Some things I've read about D7 seem to indicate this will be okay in D7. The use of "drupal_write_record" really makes this a convenient practice.
Depends on who you ask. My position is that adding a column to a foreign table is OK if the code will not be shared. IOW, custom code for your own site. It is especially OK for the user table since it has built in support for custom columns. I discourage this practice for Contrib modules since the users of the module are usually unprepared to evaluate the upgrade risks involved.
Quoting Moshe Weitzman <weitzman@tejasa.com>:
So let me add a bit to the question because I just came across it in a contrib. Let's say you need one field that exactly matches a core table. Is it ever okay, upgrades aside, to add that column to the core table? Some things I've read about D7 seem to indicate this will be okay in D7. The use of "drupal_write_record" really makes this a convenient practice.
Depends on who you ask. My position is that adding a column to a foreign table is OK if the code will not be shared. IOW, custom code for your own site. It is especially OK for the user table since it has built in support for custom columns. I discourage this practice for Contrib modules since the users of the module are usually unprepared to evaluate the upgrade risks involved.
I agree with Moshe but understand the desire to want to add to a table. The correct method for this is to create your own table relating the rows of information. You can CREATE VIEW if you want to avoid needing to supply the JOINS. Views are great for relating row ids to the text data you wish to represent. Writing the relational data is reserved for the provided hooks such as hook_nodeapi. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://www.4offer.biz/
participants (5)
-
Earnie Boyd -
Larry Garfield -
Moshe Weitzman -
Nancy Wichmann -
Steve Yelvington