I am doing a proof of concept in a line of business application where I want to swap out the current C# Code-First Entity Framework implementation with a F# one. I am following this article which seems to work pretty well, but I was hoping to use FSharp record types instead of the classes that the article uses. When I try and add a data annotation to a record type like this:
type Family = {[<Key>]Id:int; LastName:string; IsRegistered:bool}
I get the following error:
Error 1 The type 'Key' is not defined
Is there a way to use data annotations with record types? Apparently, EF Code-First needs annotations...
Record types support attributes just fine (and with the syntax you have).
Check if your reference to System.ComponentModel.DataAnnotations is in order, that's where KeyAttribute is defined.
Edit: EF wants to work with properties, that's why using a record doesn't mesh well with EF. You can still make it work in F# 3.0+ by marking the record with CLIMutable attribute (this generates property setters and a parameterless constructor which are taken for granted by C#-centric frameworks and libraries).
The article you're looking at was written with F# 2.0 in mind - CLIMutable wasn't around yet and there was no way of using records for that.
Related
I have a database with two tables, one with a column numeric (19,4) and other with float.
I need to map (in Entity Framework 5 Code First) this two tables in entities that have the same type, such as decimal. Change the database is the best solution, although is out of question.
Anyone?
Entity Framework does not support such simple mappings (yet?) that require type conversions. It is on a feature request list but apparently not decided until now if simple type mappings will get better support in the future:
http://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/2639292-support-for-simple-type-mapping-or-mapped-type-con
A workaround is to use two properties in your model, one that is not mapped to a database column and one with a type matching the actual type in the database, and then to perform the type conversion between the two properties in their getters and setters. An example for this is here:
https://stackoverflow.com/a/14221906/270591
I want to map the postgres type point to the Devart.Data.PostgreSql.PqSqlPoint structure.
I found a table (devart PgSqlTypes) in which is stated for point: "May be represented as the PgSqlPoint class or the Srting".
However in devart's Entity Developer I can only choose Dot.Net standard types like String,Byte,Int16,Int32,Boolean etc. for the generated entity's respective property and did not find a way to select Devart.Data.PostgreSql.PqSqlPoint as type.
Would this be possible somehow or will I allways have to do the conversions myself in the code of my property's getter?
Your help is much appreciated.
p.s. We are using Entity Framework as ORM framework.
Entity Framework supports only primitive types: http://msdn.microsoft.com/en-us/library/ee382832.aspx . From the Entity Framework's point of view, a PqSqlPoint is not a primitive type.
As a woraround, map the point column in the database to the string property in both CSDL and SSDL parts of your model.
Additionally, you can create a PqSqlPoint property (it will convert string to PqSqlPoint) in the partial class: http://www.devart.com/dotconnect/postgresql/docs/?Devart.Data.PostgreSql~Devart.Data.PostgreSql.PgSqlPoint~Parse.html . But it will be readonly.
We are going to support PostGIS in our Entity Framework implementation. Are you interested in this feature? If yes, we can send you our internal build before the release to take into account your remarks and suggestions in the final version.
So I have run into a situation where I need to use the Entity Framework (DbContext) with databases whose columns are not known at compile time. Basically I don't have the luxury of hard coding a customTable class to put into the DbSet.
The only thing I can think of for solving this issue is using Reflection.Emit to create a customTable class at run-time based on information I glean by interrogating a database.
I was not able to find any information of solving this issue, but I am very new to working with the Entity Framework so maybe a solution would be more obvious to someone more experienced.
I feel like there should be a cleaner way than using Reflection.Emit to dynamically create a class to feed DbSet.
If I am way off base for the intended use of the Entity Framework that information would be useful as well.
Hi I'm investigating this problem too and I have found what seems like the solution.
http://romiller.com/2012/03/26/dynamically-building-a-model-with-code-first/
tells you how to make a DbContext into which you add a new DbSet using a type as a parameter. You can create this type using the Dynamic Linq Library:
http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
It has a method called CreateClass which will allow you to dynamically build a POCO class definition from a list of field names and load it, you can then create a DbSet using the new type you have created.
You can then get a non-generic DbSet from your updated DbContext using
db.Set(type)
where 'type' is a variable holding your new type. This can be worked on using the linq predicates in the dynamic linq library.
Incidentally, my application is for a CMS where new modules can add fields to the core data table for the CMS, and I don't want to use DI as its too inflexible as no given module will be able to provide a type which has all the fields it needs and all the other unknown modules might also need.
James
Our organization is looking to standardize on Entity Framework once v4 comes out. As a result, I am looking at what it would take to migrate our application that uses NHibernate for persistence to EF4 using POCO support. In a couple of places we use single table inheritance (also known as Table Per Hierarchy). I have been unable to get it to work using the following.
Payment (base class [should be abstract but having trouble there as well])
CreditCardPayment (concrete implementation)
ACHPayment (concrete implementation)
CheckPayment (concrete implementation)
Right now, I am mapping them with only the base class properties. All of these classes are in the same namespace. They have a discrimimator that is called PaymentTypeId in the database, so the Payment mapping has a condition of "When PaymentTypeId = 0". Each of the subclasses have the same condition with different values (i.e. CreditCardPayment = 1, etc.).
When I try to load each a list of all payments using DataContext.Payments.ToList() (DataContext inherits from ObjectContext) I am getting the following exception:
"Object mapping could not be found for Type with identity 'DataLayer.DataModel.CreditCardPayment'."
I can't figure out what this means, as the POCO CreditCardPayment class lives in the same namespace as the POCO Payment class does (in fact in the same file).
What am I missing?
This is complaining not about database mapping, but model to CLR mapping.
The EF can't for some reason find your CreditCardPayment class.
Now one possible reason is that you haven't loaded the metadata for it yet.
For example if you have this:
Assembly 1:
- Payment
Assembly 2 references Assembly 1:
- CreditCardPayment extends Payment
Then when you query the EF doesn't know where CreditCardPayment lives.
The way to get around this is with LoadAssembly i.e:
using (DataContext ctx = new DataContext())
{
ctx.MetadataWorkspace.LoadFromAssembly(typeof(CreditCardPayment).Assembly);
// now do your query.
}
You need to tell to LoadFromAssembly every assembly that isn't directly reference by your DataContext class.
Note: typeof(Payment).Assembly is directly referenced because of the IQueryable<Payment> Payments property.
Hope this helps
Alex
Microsoft.
What I didn't represent before (I didn't think it relevant, but it was). Was that CreditCardPayment inherited from an intermediary class named "CreditPayment" and ACHPayment inherited from CashPayment. CreditCardPayment and CashPayment live in the same namespace and file, but were not represented in the EF mapping. Once I added those within the mapping file, everything worked ok.
So, even thought EF does not ever map to one of those types directly, it seems to need to know about them, because it changes the basetype of the CreditCardPayment classes et al. Thank you for your help on this.
Aside from faster development time (Visual Studio 2010 beta 2 has no T4 templates for building POCO entity objects that I'm aware of), are there any advantages to using the traditional EntityObject entities that Entity Framework creates, by default? If Microsoft delivers a T4 template for building POCO objects, I'm trying to figure out why anybody would want to use the traditional method.
You're asking two questions at the same time, it seems. Code-only versus model-first and EntityObject parent type versus arbitrary parent type. You get designer support with model-first, regardless of parent type. Aside from designer support, you can also use precompiled views with model-first. That can significantly help performance.
Having EntityObject as a parent can be an advantage over so-called "POCOs" (which are usually proxy bases, not "plain" objects), because the runtime type of your entities are the exact type you expect, rather than a runtime-generated subtype.
Also, unlike other ORMs which have minimal to no LINQ support, the Entity Framework has rich LINQ support, allowing you to project onto real POCO types. Therefore, it is possible to build truly persistence-ignorant presentations without having to care about what the base type of your entities are. You are not stuck with whatever type comes out of the ORM blackbox.
EntityObject allows for private properties which are persisted to the database. Using proxy types requires that those properties are at least protected and must be virtual. Therefore, EntityObject may allow for better encapsulation.
I'm not trying to suggest, by the way, that there aren't advantages to using proxies; I'm just trying to answer your question about what the advantages of EntityObject are.
I think the only benefit is designer support. Can't find any other benefits in using non-poco entities.