+1 on normalizing data into discrete columns, rather than blobs.<br><br>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.
<br><br>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.
<br><br>Down with $user->data as a serialized field.<br>
<br><div><span class="gmail_quote">On 11/22/06, <b class="gmail_sendername">Greg Knaddison - GVS</b> <<a href="mailto:Greg@growingventuresolutions.com">Greg@growingventuresolutions.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 11/22/06, Chris Johnson <<a href="mailto:cxjohnson@gmail.com">cxjohnson@gmail.com</a>> wrote:<br>> As much as I prefer to avoid serialized data when possible, there are cases<br>> where it makes sense. What is the general purpose of this move? What are
<br>> the repercussions for modules which use this column in D6? Does core use<br>> this column?<br><br>Core profile module uses this column to store fields that are admin<br>only. This can lead to database inconsistency if you have a field
<br>pulic for a while, then change it to admin only - the data stored when<br>it was public is in one table and the rest is in $user->data.</blockquote><div><br>A recurring problem with the adsense module. It uses the profile tables to hold the
<br>Adsense ID, and users are confused to no end by that.<br></div><br><br></div>