[support] User ID in users table

Sun Dec 9 01:19:36 UTC 2012

Hi Earnie
There are few more things here. As Austin mentioned db_next_id()  looks as *
Database::getConnection()->nextId($existing_id)*
 , so the nextId() plays a role here in determining the next uid.

The api nextId() , is different for different database type like for mysql
it is different , for postgresql it is different ...

Lets take the case of mysql, it makes use of a table *sequences*, in that
table, *id* column is auto increment one. every time you add a user or
delete a user, one entry is added to that table, so *id* gets new value
every time. That id value is your next user id.

To check this just delete an user and add another user, you will see the
new user id is N+2 assuming N was last max user id.

Not sure why it is implemented like this, probably missing the original
idea behind this.

Thanks
Kamal
Net Cloud Systems, Bangalore

On Sat, Dec 8, 2012 at 10:54 PM, Earnie Boyd
<earnie at users.sourceforge.net>wrote:

> 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
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20121209/70cc264d/attachment.html 