On a new site, built from scratch starting with RC3, I was managing the few registered users that has signed up so far. Then I noticed that their UID numbers are really weird. For the first few they are 1, 4, 40, 95, 108 and 115. UID4 is my user account that was created almost immediately after installing Drupal 7 RC3.

Should it really be like this? Shouldn't the UID's be incremented by 1 for each new user that signs up?

When looking in the user table, only those UID's are listed, there are no others in there.

I have duplicated this on another dev site I have, creating a second user. This time that user got UID 3, not 2 as expected.

Comments

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

FYI Drupal creates two users by default, the anonymous and admin user. So by default those have uid 1 and 2. But drupal has to manually set the anonymous user back to uid 0. So now the next uid that is available is uid 3. That's always been the case for Drupal core for a while. Not sure what else is going on with the gaps though.

tsvenson’s picture

tsvenson commented

Thanks for filling me in on that one Dave, didn't know that.

The only module I am using that does anything to users is Mollom, protecting the user reg form. I'm sure though that I added it after I created my own user account for that site. For a complete list of contrib modules used on this site see 18 Modules that Makes Drupal Mill Tick.

As mentioned, I started building this site on RC3, then updated to RC4 just before launch and then to 7.0 as soon as it was released. The problem has continued after that.

bfroehle’s picture

bfroehle commented
Priority: Normal » Minor

It comes from

$edit['uid'] = db_next_id(db_query('SELECT MAX(uid) FROM {users}')->fetchField());

in modules/user/user.module.
I think it's by design, although the gaps do seem larger than usual. (I think the gaps correspond roughly to the number of connections the MySQL server has).

tsvenson’s picture

tsvenson commented

This particular site doesn't have much traffic yet and 99+% is anonymous so a gap of 55 is for sure quite large.

jbrown’s picture

jbrown commented
Priority: Minor » Normal

Something is going very wrong here!

damien tournoud’s picture

damien tournoud commented
Status: Active » Closed (works as designed)

This is by design. The id generator is shared between users, batch ids, action ids.

Cliffy’s picture

Cliffy commented
Status: Closed (works as designed) » Active

Since it is by design, will there be any problem if I change the uid directly from the users table? Moreover, why is it beign designed in this way? Just curious.

marcingy’s picture

marcingy commented
Category: bug » support
steven jones’s picture

steven jones commented
Status: Active » Fixed

@Cliffy - You'll need to change the uid everywhere it might be stored, not just the users table, I would suggest that unless you have a very good reason to do so, then it's not worth it.

The reason that the incrementing numbers are shared is that in the MySQL database wrapper there is a single way to get the 'next numeric ID' for all calls to it. So the next ID for the user and the next ID for batches, etc. come from the same pool of numbers. Hence why you see 'missing' numbers in your users table.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

W.M.’s picture

W.M. commented
Issue summary: View changes

Has this issue been solved in the meantime? I have just noticed a gap of 1100+ at one site of mine that I have not published yet to public.