[development] Let's kill $user->data

[Khalid B]

+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 at growingventuresolutions.com> wrote:
>
> On 11/22/06, Chris Johnson <cxjohnson at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20061122/4c4e59cd/attachment.htm