Hi Folks In our development environment I created few users after quite long. I see the user ids are not increasing monotonically. I had around 5/6 users in development environment. Suddenly the UID allocated to new user is 26. Next user , UID allocated is 33. Can somebody tell how the UID is decided, I checked the table "users", there uid is not auto_increment one. On what basis UID is decided? Thanks kamal necs, bangalore
On Thu, Nov 29, 2012 at 9:38 PM, Kamal Palei wrote:
Hi Folks In our development environment I created few users after quite long. I see the user ids are not increasing monotonically. I had around 5/6 users in development environment. Suddenly the UID allocated to new user is 26. Next user , UID allocated is 33.
Can somebody tell how the UID is decided, I checked the table "users", there uid is not auto_increment one. On what basis UID is decided?
It is decided by the rules of you DB engine. The fields is an auto-incremented field. If you have gaps in the order it is possible to see this type of sequencing as the gaps are used first. -- Earnie -- https://sites.google.com/site/earnieboyd
This isn't the case in D7. UID is assigned by a SELECT MAX(uid) FROM {users}. Check user.module line 571. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 11/30/2012 8:13 AM, Earnie Boyd wrote:
On Thu, Nov 29, 2012 at 9:38 PM, Kamal Palei wrote:
Hi Folks In our development environment I created few users after quite long. I see the user ids are not increasing monotonically. I had around 5/6 users in development environment. Suddenly the UID allocated to new user is 26. Next user , UID allocated is 33.
Can somebody tell how the UID is decided, I checked the table "users", there uid is not auto_increment one. On what basis UID is decided?
It is decided by the rules of you DB engine. The fields is an auto-incremented field. If you have gaps in the order it is possible to see this type of sequencing as the gaps are used first.
-- Earnie -- https://sites.google.com/site/earnieboyd
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
Here's the only issue I could find: http://drupal.org/node/356074 From a quick reading apparently the decision was made from the old problem of User 0 (Anonymous) not being inserted at times. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 11/30/2012 8:42 AM, Earnie Boyd 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?
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/... ) -Mike __________________ Michael Prasuhn http://mikeyp.net On Nov 30, 2012, at 5:42 AM, Earnie Boyd <earnie@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/ ]
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/... )
-Mike __________________ Michael Prasuhn http://mikeyp.net
On Nov 30, 2012, at 5:42 AM, Earnie Boyd <earnie@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/ ]
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@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/...)
-Mike __________________ Michael Prasuhn http://mikeyp.net
On Nov 30, 2012, at 5:42 AM, Earnie Boyd <earnie@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/ ]
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@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@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/...)
-Mike __________________ Michael Prasuhn http://mikeyp.net
On Nov 30, 2012, at 5:42 AM, Earnie Boyd <earnie@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/ ]
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@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@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@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/... )
-Mike __________________ Michael Prasuhn http://mikeyp.net
On Nov 30, 2012, at 5:42 AM, Earnie Boyd <earnie@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
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@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@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@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@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/...
)
-Mike __________________ Michael Prasuhn http://mikeyp.net
On Nov 30, 2012, at 5:42 AM, Earnie Boyd < earnie@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/ ]
participants (4)
-
Earnie Boyd -
Jamie Holly -
Kamal Palei -
Michael Prasuhn