Using a very specific example for ultimately a more general question: How can I configure the column type convention for Code First column generation to use nvarchar(50) instead of nvarchar(MAX) for string columns?
You can change the default db type two ways:
Firstly, you can add the appropriate attribute to the property. An annotation of [StringLength(50)] specifies a length of 50.
Secondly, you can configure the property using the StringPropertyConfiguration methods.
var entityTypeConfiguration = modelBuilder.Entity<YourEntityType>;
entityTypeConfiguration.Property(t => t.StringProperty).HasMaxLength(50);
You can check the other StringPropertyConfiguration methods to see what other options are available for configuration.
Related
I am using Entity Framework Core 7.0.0 and in my OnModelCreating method I am trying to specify a column to be of type nvarchar(max).
In EF6 (not Core!), we were able to do something like:
modelBuilder.Entity<Log>().Property(p => p.Errors).IsMaxLength();
However, I am not able to figure this out in EF Core. Is there something similar available in EF Core that I am missing?
I know that it would normally default all properties of type string to nvarchar(max) but I am overriding DbContext's ConfigureConventions with the following, to default all string to 50 characters:
configurationBuilder.Properties<string>().HaveMaxLength(50);
With help of [Column] data annotation:
[Column(TypeName = "nvarchar(MAX)")]
With help of Fluent API:
entity.Property(p => p.Errors)
.HasColumnName("YourColumnName")
.HasColumnType("nvarchar(MAX)");
HasColumnName: the HasColumnName attribute is applied to a property to specify the database column that the property should map to when the entity's property name and the database column name differ.
HasColumnType: the HasColumnType method is applied to a property to specify the data type of the column that the property should map to when the type differs from convention.
My MS SQL 2014 database table has a computed property column which uses a database function. Using SQL Server Management Studio, a query against the table lists the computed property values as expected.
The Codefluent model created via the import wizard shows the Entity with the computed column as a property. The underlying .cpf file defines the property with "d3p1:compute=" and the list of parameters that are used by the database function.
When an entity or the collection of entities is loaded, the properties which are used in the computed property have values, yet the computed property has a value of nothing/null.
How do I get Codefluent to read the computed value from the database table and have the value included in the entity's properties?
This is a bit tricky. First of all, you should declare the property like any other property. Then you must instruct the SQL producer to declare a formula on that column. You can do that with a custom 'compute' attribute in the SQL producer namespace. You can set it with the Visual Studio modeler like this:
In this example I've created an int property that is just another column value multiplied by 2.
Optionally, you can declare the property to be 'read on save' because most of the time, you want to read the computed value after a save, not only on load operations:
Once this is all done, this sample console app should display 30:
class Program
{
static void Main(string[] args)
{
var c = new Customer();
c.Name = "killroy";
c.Age = 15;
c.Save();
Console.WriteLine(c.Age2); // will display 30
}
}
If Simon Mouriers solution solves your problem than that is probably the best approach. However, there are 2 other options
RAW View Method
After you create a Codefluent Entities View click on the Edit Where button and it will allow you to create a RAW View
You can than specify the advanced property "UsedForMethods".
WARNING: Related entities will use the table instead of the view. This is by design and there is an article somewhere on the knowledge center on how to get around it. http://www.softfluent.com/product/codefluent-entities/knowledge-center/
Rename SQL Tables and Create a SQL View with the Same Name as the Original Table - This method is a hack, Softfluent discourages this approach, I love it because I know exactly what is happening under the scenes. I have used it with success in a scenario in which I needed soft deletes. I have automated the process with 2 stored procedures that handle the renaming. Using this approach requires running one of the stored procedures to undo the name changing prior to building the model. The other stored procedure handles the renaming after building the model. I'll post the stored procedures and how I use them within a couple of days.
Is there a way to specify default values for columns when i use code first approach
Yes, you will set default values in default constructors of your entities.
I'm working on a custom entity framework provider and I need to add support for default column values for this provider. When the user uses the entity framework wizard and selects a table that includes columns with default values, those default values are not being populated into the entity designer.
I'm a little lost on where exactly this population should take place. I believe the appropriate place would be in the GetEdmType method override of DbXmlEnabledProviderManifest but I just don't see how to set the default value, if this is the correct place.
Anybody has experience writing EF providers that support default values for table columns? How do you implement this?
I am a bit late to the party but DbXmlEnabledProviderManifest is not the right place for adding default values. The provider manifest describes capabilities of the database engine itself and is specific (and general) to this database engine and not to a given database and/or table. The default value in the provider manifest tells EF what value to use for the given column property if one is not provided by the user (e.g. if the user user does not specify scale or precision for a decimal column the value from provider manifest will be used for scale and/or precision used for this column).
If you want just to insert a default value for a property the easiest way is to set the property that corresponds to the column on your entity to this value in the constructor. This way the user can always set it to a different value but if s/he does not the default value will be sent to the database. For some corner case scenarios where some of the columns in the database do not have corresponding properties on entities you can use DefaultValue attribute on the Property element in SSDL which will be inserted to the database when you add a row. This is especially useful if those properties are not nullable since without telling EF what value should be inserted EF would try inserting null which would obviously fail for non-nullable columns.
When we have two entities in EFv4 EDM diagram and only one table for both in the database (for instance, having table Documents and entities Invoice and Qoute), table Documents having documentTypeId column as a discriminator and set this column as a discriminator in the EDM (in Table mappings), how do we read the value of this property in our code?
We cannot assign values to it because EF does it for us under the hood (based on what we entered in Table mappings for condition) but somehow I don't get it why we are also not allowed to read it.
Imo this property is already mapped so you can't map it again. It is used to determine type of materialized entity. Why do you need such column. Usually it is enough to use is operator like:
var document = context.Documents.GetById(id);
if (document is Invoice)
{
...
}
If you only need to select subtypes you can use OfType extension method like:
var invoices = context.Documents.OfType<Invoice>().ToList();
You also don't need to set this value when adding new entity because you are adding subtype - Invoice or Quote.
Edit:
As I understand from your comment you don't need this information in query. In such case you don't need to map it. Simply use partial class of your entity and add custom property which will return your string. Sound like stupid solution but actually it would be the easiest one.
Discriminator column should be part of mapping metadata so in case of T4 template generating your entities, it could be possible to update the template so it generate such property for you.
You may want to use a single-table inheritance hierarchy, as described here.
That way, you could have an abstract Document class that includes a DocumentTypeId column. Invoices and Quotes would extend this class, but specify certain DocumentTypeId filters. However, because the original class has a DocumentTypeId column, they would each have that column as well.
Another advantage to this approach is that you could create utility methods that can act on any Document, and you could pass any Invoice or Quote to these methods.