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.
Related
I downloaded a sample database for Postgres (v14) (dvdrental) so I could follow some SQL tutorials. I wanted to create an ASP.NET Core (5) Web API for that database, so using scaffolding, I created the entities based on the database tables and columns, then after some minor changes, I wanted to create a new migration.
That step failed though, as I'm getting two errors (so far) regarding the data types.
The property 'Film.Fulltext' is of type 'NpgsqlTsVector' which is not supported by the current database provider. Either change the property CLR type or ignore the property using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'
I tried to use [NotMapped], but got the same error. I also tried to specify
[Column(Typename = "tsvector")]
which is the official type mapping according to https://www.npgsql.org/doc/types/basic.html, but for some reason, EF core seems to ignore it completely and gives the same error.
The property 'Film.SpecialFeatures' could not be mapped because it is of type 'string[]', which is not a supported primitive type or a valid entity type. Either explicitly map this property, or ignore it using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'
Which is, again, weird, as the Postgres websites says
public string[] Tags { get; set; }
The provider will create text[] columns for the above property..
So basically EF Core throws errors about something that is the officially recommended way of doing it, so I have no idea why these errors even occur or how I could solve them.
Any help is appreciated.
Thanks
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.
Entity Framework Code First best practice question?
Hi All I am using EF codeFirst 6 on an NTier app.
I have found that poco object that I am using to map to EF are really EntityFramework specific. Let me give you an example
If I want to add a property that is not related to EF in the object ,EF does not like it.
I Read you can put the "NotMapped" attribute however it start making this object difficult to maintain .
Also there might be developers that are not familiar with EF and that will not understand the issue.
My question is it good practice to keep EF Entity Models separate and have a dto to convert to/from to a Domain Model where
a developer can do what he likes with it without interferring with EF Model which is clearly a 1 to 1 with the tables in the database
Any Suggestions?
Your problem could be resolved by using the Fluent API approach instead of the Attribute-based (Annotations) approach. See Entity Framework Fluent API.
You would configure your entity mappings in the DBContext rather than in the entity classes.
From the above linked article:
Specifying Not to Map a CLR Property to a Column in the Database
The following example shows how to specify that a property on a CLR
type is not mapped to a column in the database.
modelBuilder.Entity<Department>().Ignore(t => t.Budget);
that would mean "ignore the Bugdet property in the Department entity."
I'm using the SQLite provider for Entity Framework 5 but it doesn't support CreateDatabase and thus cannot auto create the database. (Code First)
Is there a way I can obtain the Model schema at runtime so that I can create the SQL "CREATE TABLE" command myself?
If not at runtime, some other way to obtain the schema so I know how to create the table properly?
Thanks!
A) As for obtaining the model schema at runtime part
(all are earlier posts of mine)
See this one How I can read EF DbContext metadata programmatically?
And How check by unit test that properties mark as computed in ORM model?
Also this one for a custom initializer Programmatic data transformation in EF5 Code First migration
Having said that...
The problem I see is where and at what point you actually have the data available.
Actually I'm quite sure you won't be able to do that at any time.
Because to be able to extract that info you need to have a DbContext running - so db has to be constructed etc. etc.
In the initializer maybe - but using different ways to get that info - the above is not available.
B)
The other way would be to go the way of implementing a provider, generator etc. (e.g. this post).
That way you should get all that info just at the right time from the EF/CF itself.
However I haven't played with that much.
For more info you can check the EF source code
This is more of a 'gathered info' so far - in case it helps you get anywhere with it. Not really a solution. I'll add some more tomorrow.
EDIT:
To get the real database metadata, look into the other DataSpace, this should get you to the right place...
(note: things tend to get less exact from here - as obviously there isn't the right official support)
var ssSpaceSet = objectContext.MetadataWorkspace.GetItems<EntityContainer>(DataSpace.SSpace).First()
.BaseEntitySets
.First(meta => meta.ElementType.Name == "YourTableName");
If you look up in debugger, Table property should have the real table name.
However, reflection might be required.
How I can read EF DbContext metadata programmatically?
How check by unit test that properties mark as computed in ORM model?
Programmatic data transformation in EF5 Code First migration
Entity Framework MigrationSqlGenerator for SQLite
http://entityframework.codeplex.com/
Entity Framework - Get Table name from the Entity
ef code first: get entity table name without dataannotations
Get Database Table Name from Entity Framework MetaData
http://www.codeproject.com/Articles/350135/Entity-Framework-Get-mapped-table-name-from-an-ent
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