Let's kill $user->data
Hi, Two steps a) We remove $user->data handling code from D6 core. No save, no load. New installs won't have this column. b) D7 will drop the $user->data if it exists. (SELECT * FROM user, $account = db_fetch_array, if(isset($account['data'])) -- no need for DDL to check for a column). This way D6 contribs can clean up $user->data and migrate to their own tables. Regards NK
As much as I prefer to avoid serialized data when possible, there are cases where it makes sense. What is the general purpose of this move? What are the repercussions for modules which use this column in D6? Does core use this column? ..chrisxj On 11/22/06, Karoly Negyesi <karoly@negyesi.net> wrote:
Hi,
Two steps
a) We remove $user->data handling code from D6 core. No save, no load. New installs won't have this column. b) D7 will drop the $user->data if it exists. (SELECT * FROM user, $account = db_fetch_array, if(isset($account['data'])) -- no need for DDL to check for a column).
This way D6 contribs can clean up $user->data and migrate to their own tables.
Regards
NK
On 11/22/06, Chris Johnson <cxjohnson@gmail.com> wrote:
As much as I prefer to avoid serialized data when possible, there are cases where it makes sense. What is the general purpose of this move? What are the repercussions for modules which use this column in D6? Does core use this column?
Core profile module uses this column to store fields that are admin only. This can lead to database inconsistency if you have a field pulic for a while, then change it to admin only - the data stored when it was public is in one table and the rest is in $user->data. I don't know why that is the case, but it is. Presumably this would get changed somehwere along the way with Karoly's proposal. That makes more sense to me. Greg
+1 on normalizing data into discrete columns, rather than blobs. Modules can always have a user_MODULE table with uid as the key, and whatever else columns needed for this (e.g. userpoints and a 100 other modules alreaqdy do that). The penalty here is an extra join, but we avoid problems such as we have with $user-data. Suppose I want to select (a count of) all users that have x = 2. How do we do that today with $user->data? Every single user has to be returned in PHP, unserialized, checked and returned. As opposed to the better way of letting the database backend do the filtering for you and return only those that meet that condition. Down with $user->data as a serialized field. On 11/22/06, Greg Knaddison - GVS <Greg@growingventuresolutions.com> wrote:
On 11/22/06, Chris Johnson <cxjohnson@gmail.com> wrote:
As much as I prefer to avoid serialized data when possible, there are cases where it makes sense. What is the general purpose of this move? What are the repercussions for modules which use this column in D6? Does core use this column?
Core profile module uses this column to store fields that are admin only. This can lead to database inconsistency if you have a field pulic for a while, then change it to admin only - the data stored when it was public is in one table and the rest is in $user->data.
A recurring problem with the adsense module. It uses the profile tables to hold the Adsense ID, and users are confused to no end by that.
Karoly Negyesi wrote:
Hi,
Two steps
a) We remove $user->data handling code from D6 core. No save, no load. New installs won't have this column. b) D7 will drop the $user->data if it exists. (SELECT * FROM user, $account = db_fetch_array, if(isset($account['data'])) -- no need for DDL to check for a column).
This way D6 contribs can clean up $user->data and migrate to their own tables.
yes - this is long overdue. ... that column causes problems for the cascading variable system that adrian proposed. one way for custom modules to move away from that column is to simply add a properly named column to users table, and save data there. no further code is required for simple fields. so this can be done as a module update and no module code needs to change. i recommend this method mainly for custom modules on sites, not for contrib/core modules. those should use own table. custom columns in users table get automatically loaded/saved - a nice, little known feature of user.module.
I recently wrote a module that makes use of this column. My module allows for "anonymous" posts. Similar to what the contributed Authorship module does. (My module is specialized for a particular client, I have no plans to contribute it as an alternative to Authorship). When this module is enabled, some posts will say something like "Submitted by an executive in the software industry" where they would normally say "Submitted by UserX". I store the information that populates the "anonymous" submitted by info in the user data column. This is handy to me for two reasons. First, I did not have to create another database table. Second and more important, the user data column gets loaded with every node. This means I need no new queries to display my information in every teaser and page view. I have no idea whether is by design or not (because the data field is not documented as far as I know), but it's convenient for my case. It's true that I can make my module work with or without the data column. So if you want to take it away, I will not complain. But I wanted to let you know I found it useful, in case that factors into the decision. -Dave On Wednesday 22 November 2006 00:58, Karoly Negyesi wrote:
Hi,
Two steps
a) We remove $user->data handling code from D6 core. No save, no load. New installs won't have this column. b) D7 will drop the $user->data if it exists. (SELECT * FROM user, $account = db_fetch_array, if(isset($account['data'])) -- no need for DDL to check for a column).
This way D6 contribs can clean up $user->data and migrate to their own tables.
Regards
NK
participants (7)
-
Chris Johnson -
Dave Cohen -
Greg Knaddison - GVS -
Karoly Negyesi -
Khalid B -
Moshe Weitzman -
Vladimir Zlatanov