4

The ASP.NET Identity code for MVC/EF stores the userid as a nvarchar(128). This looks like a GUID. I prefer using sequential GUIDs for an ID/Private Key to improve performance. How can I verify that the code generating the GUID for ASP.NET Identity is sequential? I'm having trouble finding that part of the code base.

Bill
  • 314
  • 1
  • 10
  • 4
    You can use an `Int32` instead of `GUID`, why do you bothered about the performance? If its a PK on the table, it is indexed. – Ofiris Jan 28 '15 at 16:23
  • 1
    It's probably database-generated. It likely won't be sequential because of potential collisions, anyway. Having it be sequential won't actually help performance. – Casey Jan 28 '15 at 16:30
  • 1
    Please don't tell that sequential Guid don't improve performance: http://stackoverflow.com/questions/170346/what-are-the-performance-improvement-of-sequential-guid-over-standard-guid. You can read this question. – mybirthname Jan 28 '15 at 16:41
  • @mybirthname Fair enough. Actually, that question points out the thing about newsequentialid, which reminds me -- EF will actually generate the database using newsequentialid if you're using SQL Server, but not if you're using Azure, since it's not supported there (because of concurrency concerns). So that probably answers the OP's question -- it will (probably) be sequential if he's using traditional MSSQL. – Casey Jan 28 '15 at 17:13

2 Answers2

2

Identity is built to work with different persistence technologies. I even seen the implementations of Identity storing data on Azure Tables which is not relational database.

Sequential GUID is only a feature of SQL Server and even not every version of SQL Server supports Sequential GUID (SQL Azure does not know about sequential GUIDs for example).

But if you set User.Id to be of type Guid and use SQL Server that supports sequential ids, your tables will be created with Ids of type sequentialguid.
I can verify that - I had troubles with types a few times trying to port locally created DB into Azure SQL.

Update

What I recommend is to change ID into Guid - same as other recommendations to make it int - you'll find plenty of guides online how to do it. The place where ID is generated is here:

namespace Microsoft.AspNet.Identity.EntityFramework
{
  /// <summary>
  /// Default EntityFramework IUser implementation
  /// 
  /// </summary>
  public class IdentityUser : IdentityUser<string, IdentityUserLogin, IdentityUserRole, IdentityUserClaim>, IUser, IUser<string>
  {
    public IdentityUser()
    {
      this.Id = Guid.NewGuid().ToString();
    }

    public IdentityUser(string userName)
      : this()
    {
      this.UserName = userName;
    }
  }
}

This is part of the framework from a decompiler. It is most likely you already inherit from this class to create your own ApplicationIdetntityUser.

However, if you so keen on sequential guid, the most safe way for that is to let SQL Server to create them for you. And you can do by adding [DatabaseGenerated(DatabaseGeneratedOption.Identity)] on Guid Id property of your user object.

You can generate sequential guids yourself, but eventually you will run into collision from different threads. I suggest you don't waste your time and let SQL Server to do the job for you - there are inbuilt mechanisms there.

trailmax
  • 34,305
  • 22
  • 140
  • 234
  • You say to set the User.Id to Guid...this is the same as other instructions to change it to type int? It appears that EF code first generates the id value. This means MSSQL is probably not generating the id field...which implies that there is a piece of code somewhere generating the id. That piece of code is what I'm looking for. – Bill Jan 28 '15 at 20:02
2

Trailmax has touched most of the main points already, but switching to sequential Guids when available is something we have been considering doing for the default EF identity implementation for Identity 3.0.

Hao Kung
  • 28,040
  • 6
  • 84
  • 93