[support] User ID in users table

Kamal Palei palei.kamal at gmail.com
Sat Dec 8 01:49:30 UTC 2012


Hi Folks
Yes, you are right.

The db_next_id is actually playing the trick here, and UIDs will be always
unique.

The db_next_id, actually does *
Database::getConnection()->nextId($existing_id);* and so the ID allocated
to new user actually is under DB's control.

Now precisely my worry is, in my local environment I have added 100s of
users. Before putting to production environment I will be deleting all
users except admin user.  And I want the users IDs should again start again
from 2 and should be continuous like 2,3,4,5,6,7,8 etc..

What I need to do so that I can achieve it?

Had it been an auto increment field, I could have set it in data base the
next auto increment value (through phpmyadmin->Operations->AUTO INCREMENT).

Now I am clueless, the only option is take a fresh copy of Drupal 715,
create again menus, nodes .., No No way...

If you have a better option to reset everything except nodes, new content
types, main menu, secondary menu etc..., please let me know...


Thanks
Kamal





On Sat, Dec 1, 2012 at 1:51 PM, Kamal Palei <palei.kamal at gmail.com> wrote:

> Jamie, All
> Thanks for info.
>
> If this is the case, I would expect user id to be monotonically increase.
> I can see my users table, the UIDs follow as
>
> 0,1,2,3,4,5,6,24,25,26,33,40,41,42
>
> I do uninstall / install of my custom modules, but I hope that is no way
> related to uid selection.
>
> Just wondering what may cause this.
>
> Also I delete nodes sometimes.., can that cause this issue, I hope it is
> unlikely...
>
> Regards
> kamal
> necs, blr
>
>
> On Sat, Dec 1, 2012 at 1:26 PM, Jamie Holly <hovercrafter at earthlink.net>wrote:
>
>> UID is figured by select max(uid). Here is the exact code from
>> user.module:
>>
>>   if (empty($account->uid)) {
>>          $account->uid = db_next_id(db_query('SELECT MAX(uid) FROM
>> {users}')->fetchField());
>>        }
>>        // Allow 'created' to be set by the caller.
>>        if (!isset($account->created)) {
>>          $account->created = REQUEST_TIME;
>>        }
>>        $success = drupal_write_record('users', $account);
>>
>> $account->uid == 0, which is the same as empty.
>>
>> Other modules can influence this via the API, such as hook_user_presave,
>> but for the core functionality, this is how the UID is figured.
>>
>>
>> Jamie Holly
>> http://www.intoxination.net
>> http://www.hollyit.net
>>
>> On 11/30/2012 9:44 PM, Michael Prasuhn wrote:
>> > No. If if was just using SELECT MAX(uid) FROM {users} then it wouldn't
>> have gaps like the OP was experiencing.
>> >
>> > Note that the result from that query is actually fed to db_next_id()
>> which in turn uses a DBMS specific method to ensure unique IDs. (In MySQL
>> this means using an insert query into a table that is set to auto increment
>> and then reading the ID of the inserted record. This cannot produce
>> duplicate keys. see
>> http://api.drupal.org/api/drupal/includes%21database%21mysql%21database.inc/function/DatabaseConnection_mysql%3A%3AnextId/7)
>> >
>> > -Mike
>> > __________________
>> > Michael Prasuhn
>> > http://mikeyp.net
>> >
>> > On Nov 30, 2012, at 5:42 AM, Earnie Boyd <earnie at users.sourceforge.net>
>> wrote:
>> >
>> > > On Fri, Nov 30, 2012 at 8:32 AM, Jamie Holly wrote:
>> > >> This isn't the case in D7.  UID is assigned by a SELECT MAX(uid) FROM
>> > >> {users}. Check user.module line 571.
>> > >
>> > > Unless the whole users table is locked then this is guaranteed to fail
>> > > under heavy use.  Some poor user is going to get a DB error of
>> > > duplicate key.  The chances may be small but there is a chance it will
>> > > happen.  Do you know the issue # that caused this to happen?
>> > >
>> > > --
>> > > Earnie
>> > > -- https://sites.google.com/site/earnieboyd
>> > > --
>> > > [ Drupal support list | http://lists.drupal.org/ ]
>> >
>>
>> --
>> [ Drupal support list | http://lists.drupal.org/ ]
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20121208/82162621/attachment.html 


More information about the support mailing list