[support] User ID in users table

[Earnie Boyd]

Since the user table doesn't have an auto increment field as has been
discussed already, simply deleting all users except UID 0 and UID 1
would cause the methods to use 2 as the next id.  However, you need to
ensure you don't have nodes and other data dependent on the created in
the DB as well.  Otherwise when someone signs up your development/test
data would be assigned to them.

Earnie

On Fri, Dec 7, 2012 at 8:49 PM, Kamal Palei <palei.kamal at gmail.com> wrote:
> 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/ ]
>>
>>
>
>
> --
> [ Drupal support list | http://lists.drupal.org/ ]



-- 
Earnie
-- https://sites.google.com/site/earnieboyd