Microsoft.AspNet.Identity.EntityFramework -
Objects UserIdentity and RoleIdenity have Id fields of type string, and thus the tables created have data types nvarchar(128).
Shouldn't these objects Id properties be of type System.Guid and the database have datatypes of uniqueidentifier? Why aren't they? A GUID is inserted on new User and Role creation.
It's most likely because the api is storage provider independent so the kept the field types as generic as possible: http://blogs.msdn.com/b/webdev/archive/2013/06/27/introducing-asp-net-identity-membership-system-for-asp-net-applications.aspx
"If your application requirements are that this information might be stored in a different storage mechanism such as SharePoint, Azure Table Service, No Sql databases etc. it is now possible to plug in different storage providers."
Hao Kung from the ASP.NET team wrote this in a comment on this question on how to change id type to int.
So we decided on string keys to avoid having to deal with key serialization issues, the EF default implementation could have used ints as the primary key, GUIDs were just an easy way to generate a random unique string key.
Another reason for a string user ID may be that strings are hard coded into the claims API, specifically, Microsoft.AspNet.Identity.IdentityExtensions.GetUserId, which uses System.Security.Claims.Value, both of which return strings.
Related
I'm new to CosmosDB and I need to store there some simple key/value pairs.
Is it mandatory to have a value of a collection a json format? If not, what can I mention as partitionKey?
Is it mandatory to have a value of a collection a json format?
The short answer is yes, Cosmos DB is no-sql database which contains key-value structure document. The document has a flexible schema, de-normalized data, it can have mixed type of data such as a string value, number, array or an object. More details,please refer to this guide.
If not, what can I mention as partitionKey?
Per my experience, when you design the partition key, you need to consider many factors.There is a nice paragraph listed here for your reference about choosing pk. My suggestion is that you could pick the most frequently queried column as pk.
I am using ASP.NET identity in MVC 5 and wondered the best way to perform string comparison during say, a query to a table where records have been entered with the userId as an foreign key.
Normally I would just plump for == but I wasn't sure how the string for a userId inside .NET identity is created.
I guess it's actually a GUID of sorts under the hood so I'd presume that == would be fine but I wondered if the culture or case would come into it at all.
Does anyone know if the string is a unique GUID for == type comparison, or should I be using string.Equals and some StringComparison option to account for cultures?
ASP.NET Identity can use GUID for keys. In that case GUID should not have any culture specific characters. So StringComparision. InvariantCultureIgnoreCase should go for string.Equals in C#. ToLower (ToUpper) can be used for SQL queries (LINQ).
You probably want to use Ordinal/OrdinalIgnoreCase StringComparisons here as it compares strings character by character without regard to linguistic convention.
Read more here: https://msdn.microsoft.com/en-us/library/cc165449.aspx
And here: https://msdn.microsoft.com/en-us/library/system.stringcomparison(v=vs.110).aspx
Code samples:
string1.Equals(string2, StringComparison.Ordinal);
string1.Equals(string2, StringComparison.OrdinalIgnoreCase);
I'm trying to understand why the new ASP.NET Identity tables stopped using Guid (uniqueidentifier type) as keys - instead it is now using nvarchar(128) but still keep a Guid as a string...
Isn't it a huge waste? (uniqueidentifier is just 2 integers vs the whole Guid as a 36 character string)
I'm suspecting that Entity Framework might be responsible for this...
Is it safe to change back to uniqueidentifier keys?
Can anyone tell me what are the benefits of using 36 character strings?
Identity is built to work on multiple storage platforms and not every storage platform has Guid as a supported storage type.
You can change the default string pkey into Guid, but that involves some work on your C# models. Or you can change the pkey into an int - whatever you like. Just be aware that there is a huge debate about which is better.
It is specifically mention that WAMS needs a int ID column to work in SQL Azure. However when developing enterprise apps over distributed databases, GUIDs are the preferred Primary key to have. How does one get around avoiding int ID column and support GUID?
If that cannot be done then how does one go about syncing data on the cloud from multiple standalone databases on various tablets/mobile the app using WAMS is running on?
An update on this issue - as of last week, the mobile services now support arbitrary strings as the ids for the column - check out this post for more information. You can now insert data with an 'id' value (which you couldn't before), so you can use a Guid value on insert. Also, if you don't send anything on the Id column on insert (or that value is set to null), the server will by default generate an unique identifier for the column.
At present, I don't think that its possible to use a GUID in the ID column. The documentation for the Mobile Services server side scripts specify that for the Delete function, the ID must be a javascript Number type. As far as I can see, all of the available sample code, and the code that you can download from the portal is quite explicit in using an integer type for the ID.
You'll have to come up with a way of generating a unique integer value whenever a new record is created. The example here uses a tick count in Insert script, which is probably OK for a low volume application, but it would need to be made more robust, perhaps by generating a number based on the user's identity and combining it with the tick count.
I'm a little late to this but I have found you can use a GUid as a primary key to a mobile services table. A couple of points though. Set the JSON property to lower case "id" and use a nullable guid, this allows inserting when there a default on the id column (NewId())
[JsonProperty(PropertyName = "id")]
public Guid? Id { get; set; }
Ash..
I'm looking to use a slightly modified ASP.Net Membership Provider to handle the standard user account creation/authentication/etc in a website. We have a fair amount of legacy data that I need to migrate in order to provide continuity with our existing users' saved information (like order history, wishlist, etc). [NOTE: We have to migrate anyway, so this is not the reason we're migrating data]
I'm wondering what a sensible approach is for joining this additional data to the asp.net membership tables. There are a two unique keys that I could use on the user table - UserId or email - which we will use as a surrogate for username.
My question is, what is the better access pattern (and hence foreign key) to use elsewhere in my tables for storing orders, wishlists, etc?
In HttpContext, a User object is available that contains the "Username", our email address,
but doesn't have the Guid for userId available.
I see 3 options:
I'd like to simply use the uniqueidentifier UserId for efficiency of access over a lengthy varchar email address, but it doesn't appear readily available without extra database calls to fetch it via email/login. Is there some way to get the UserId so I can make it the foreign key on different tables?
I can pass in email address (username) as the input parameter, join on userId where email address = #emailAddress, and use userId as the foreign key on other tables.
Not viable
I can store username/email address on all the other tables as a foreign key - which would be an unfortunate denormalization
Any thoughts on a best method from either a DB perspective or from an application efficiency perspective?
You can get UserId:
MembershipUser myObject = Membership.GetUser();
string UserID = myObject.ProviderUserKey.ToString();
or maybe (please, check it)
string userId = Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString();