Re: [development] User Status [WAS: User last access]
----- "Ivan Sergio Borgonovo" <mail@webthatworks.it> wrote:
Hopefully MySQL is going to fix this kind of quirks and come up with a decent boolean implementation and you may end up in a not so efficient, hardly portable mess.
There's no industry-standard way to handle booleans, so I'm not sure what you mean by "fix this kind of quirks" when any efficient boolean implementation would be defined by you as a quirk.
"Make the common case fast." <http://en.wikipedia.org/wiki/Amdahl%27s_law>
It can't be read as you're advertising it. You can't optimize the most used DB and make the overall application run faster on all DB.
Any optimization we make for MySQL has a huge impact on the base of Drupal installations. Any optimization we make for other DBs has a negligible impact. Therefore, it behooves us to spend our time concerned with optimizing for MySQL and merely verifying the correctness of implementations in other databases. Amdahl's law applies because it establishes the relationship between an optimization and the overall impact on performance. If over 98% of Drupal installations use MySQL and 100% of Drupal installations use the user table, then an optimization to how we manage the user table in MySQL has a huge impact on overall performance. If under 2% of Drupal installations run PostgreSQL, then an optimization for PostgreSQL has minimal impact.
What about: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." D. Knuth
This is exactly why I support TINYINT(1) UNSIGNED NOT NULL or CHAR(0) on MySQL. CHAR(0) is portable as CHAR(1) on every database except Oracle. TINYINT(1) UNSIGNED NOT NULL is portable as larger unsigned integer formats on other DBs. 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.
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
Quoting Larry Garfield <larry@garfieldtech.com>:
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?
How about a suspend column which gives a count down timer in days for how long the user is blocked? Cron would handle the count down and when going from 1 to 0 would set is_blocked to FALSE. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
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
On Mon, 5 May 2008 16:46:14 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
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)
What about null? If D7 is going to support prepared statement through PDO we could make good use of nulls. If the hooks are going to stay the same they should suggest what to log: * view (I don't think is useful to log view time of a user profile, maybe the number of times a profile has been seen, but that would imply some "anti-spam" mechanism) * insert * login * logout (interesting) even if it's interpretation and uses may be tricky, it could still find a better place in a module that actually know what to do with this data unless there is no more uid once the execution reaches the logout hook. * update BTW it would be nice if sid could be accessed for anonymous users too so to have a uniform access to sid for anonymous and registered users. I patched my D5 to have ->sid for anonymous users... I could give a look to D6 see if the patch can be applied and submit it for review.
- last edit time (by anyone) - is_blocked (boolean, sadly this is the inverse of the current status column) - What else?
The countdown is nice... but what about another date? that will be safer/easier to manage if you skip some cron run. Anyway I see this feature more suited to contrib since it may have a lot of variations. eg. the is_blocked itself could be a date. If null it is not blocked, if a date in the future it is blocked, if a date in the past, unblocked... and it could also serve as a short term log. But still I see so many way that users could be blocked/unblocked that I'd leave it to contrib/other table. eg. I may decide to block users after a certain period they have been registered in spite of un-blocking them after a certain period, block them if they don't log in in a certain period, if they don't add content etc... While the info about when they logged in, edited their profile etc... fits in the users table other things may be more suited to external tables/modules. If there will be some refactoring in the users management/creation etc... it should become easier to hook other tables to the main users table. OT: I'd like the creation/editing of users to become atomic, so that if you use the insert/update hooks you don't risk to end up in half created users. Deletion can be easily achieved if you can use references and rules. -- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (5)
-
David Strauss -
David Timothy Strauss
-
Earnie Boyd -
Ivan Sergio Borgonovo -
Larry Garfield