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@garfieldtech.com> Date: Mon, 5 May 2008 16:46:14 To:development@drupal.org Subject: Re: [development] User Status On Mon, 5 May 2008 15:53:22 -0500 (CDT), David Timothy Strauss <david@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