[development] User Status

[David Strauss]

Really, this isn't a debate about anything more than how we store boolean fields. Because we'll be using booleans in at least one important area (the user or node table) a discussion of how to implement the booleans isn't premature.

It's also not premature to discuss booleans in the user table because we've been using a status bit for at least the last few Drupal versions. If we end up *changing* what data we store (a separate discussion at this point), we can consider scapping this discussion.

We don't have such a long development cycle that I'm content to wait for design changes (that may never happen) in order to begin optimization of what we've used for quite some time.

-----Original Message-----
From: Larry Garfield <larry at garfieldtech.com>

Date: Mon, 5 May 2008 16:46:14 
To:development at drupal.org
Subject: Re: [development] User Status



On Mon, 5 May 2008 15:53:22 -0500 (CDT), David Timothy Strauss <david at fourkitchens.com> wrote:

> You're misunderstanding Knuth if you think we should care about storage
> space or performance on non-MySQL databases. Optimizing for MySQL is not
> premature optimization.

Since we haven't even decided what data we want to store, talking about the database field type at all is premature.  If we need a boolean field in the database, let's add a schema field type for it and let each database define its own equivalent.  As long as we can read/write to it with 1/0 for true/false, the exact details of the field are irrelevant.

The more important question is what metadata fields do we want on the user object/user table?  Off the cuff I can think of:

- created time
- last access time (0 means never logged in)
- last edit time (by anyone)
- is_blocked (boolean, sadly this is the inverse of the current status column)
- What else?

(I am specifically leaving out uid, email address, login name, display name, and other things already accounted for or in discussion.)

--Larry Garfield