+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.