Looking through the documentation I don't see a GUID datatype. Is there a function or something to generate a random GUID? What is it?
$System.Util.CreateGUID()
This doesn't return a data-type however, it's just a string. You can write your own data-type class if you need special validation or conversion between logical/display/ODBC.
Related
I need to be able to encode string values into unique GUID representation so that when a GUID is passed back to the algorithm, it could decode it into an original string.
So, for instance, it would be able to take a string, 'API Users' and return a GUID, for instance: b0363782-5207-420e-9188-6bff7369593
Then when passed 'b0363782-5207-420e-9188-6bff7369593' it would return 'API Users' back.
Is creation of such mapping algorithm possible in theory?
Of course, I can persist the mapping in the storage and then relate back the string to an issued GUID, but I am looking for an encoding-based way of doing it so that the resulting GUID would store the string.
So I stumbled upon this article earlier today
https://blogs.msdn.microsoft.com/azuremobile/2014/05/22/tables-with-integer-keys-and-the-net-backend/
In the article, the author makes a comment that got my attention. He said
Note: Typically, when starting from an Entity Framework Code-First model in your .NET Backend, you would use string ids
From what I've read, using string Ids can be a performance issue in as your table grows. So I would just like to know if this was just the authors opinion or it is a standard. If it is the later, I would like to know the reasons behind this.
IMHO identity field should be numeric for performance reasons matching int is way much faster than matching string and numeric field saves a lot of space than string.
Technically yes, you can use the string as primary key, but if a string makes sense to be the primary key then you should probably use it. You have to take in your account some consideration.
Digtis comparison is faster then string comparison
Longer string mean harder to compare
When you must use a string as primary key then set the length e.g. MaxLength = 20 = nvarchar(20)
public class User
{
[Key, DatabaseGenerated(DatabaseGeneratedOption.None), MaxLength(20)]
public string UserId { get; set; }
....
This will help you to avoid some performance issues.
You can also change the generated key from nvarchar to varchar by using dbcontext.executesqlcommand this will give you more space (One charachter will use only one byte and not 2).
Alternatively, you can with code first change the column data type as following:
[Key, DatabaseGenerated(DatabaseGeneratedOption.None), Column(TypeName = "varchar"), MaxLength(20)]
public string UserId { get; set; }
....
I'm trying to generate JPA entities from tables using eclipse plugins, I defined some BIG INT and Date columns. I would like to have long type in Entity class for those BIGINT columns, But It generates as String. Please help me how to resolve it?
Sounds really weird that the Eclipse plugin generates those columns as String - check that you haven't missed / misread something.
If the column really is a BIG INTEGER in the database, just changing the type of the property field to Long should do the trick.
I don't know exactly what do you mean long properties, but try to use #Type annotation. Example:
#Type(type = "org.hibernate.type.LongType")
Is there a way to tell EF 4.3+ not to update some fields?
We have a standard in the DB where each table has a 'CreatedBy' column. I would like to make sure that it is impossible to update that column.
The safest I see it would be to tell EF not to map the corresponding properties but just for the update.
Is there a way to do that?
If you are using code first you can use the DatabaseGenerated attribute to configure the property as Computed.
[DatabaseGenerated(DatabaseGeneratedOption.Computed)]
public string Foo { get; set; }
Essentially I have a table with zip codes in it. The zipcode field is defined as 'char(5)'. I'm using code first, so I've put these attributes on my ZipCode property:
[Key, Column( Order = 0, TypeName = "nchar"), StringLength(5)]
public string ZipCode { get; set; }
Now if I query against this in EF:
var zc = db.ZipCodes.FirstOrDefault(zip => zip.ZipCode == "12345");
The generated SQL uses nvarchar(4000) to inject the parameters. Huh? Is it because "12345" is technically a string of unknown length? Shouldn't EF be smart enough to just use the proper "nchar(5)" when querying that table?
I ask because the nvarchar(4000) query takes half a second whereas the properly-scoped query is much faster (and less reads).
Any assistance/advice would be appreciated.
This is to take advantage of auto parameterization. The following article explains the general concept as well as why specifically nvarchar(4000) is used.
http://msdn.microsoft.com/en-us/magazine/ee236412.aspx
Have you tried using the MaxLength attribute? This article gives a decent summary of how the various data annotation attributes are interpreted by EF.