I am trying to create an OData service for an entity with a System.Data.Entity.Spatial.DbGeography type property. The entity is part of EntityFramework context (database). Getting the data in/out of the Db works fine. I am able to request the data from OData service. It is returned as a WKT string. However, when I POST a similar entity back to insert a new record into the Db, I get the error "no parameterless constructor" from the framework. It is the DbGeography constructor referred I guess, because when the property is set to null in the POST request, all is fine.
I found that OData should be working better with System.Spatial.Geography (I used System.Spatial.GeographyPoint). Even then it complaints about the IConvertible interface not implemented when I post data.
Is there any "direct" way of getting the data out and into the OData service using the Entity.DbGeography (and similar) types? I found some ways of binding in case of using MVC models and controllers - would similar action be needed here? Or should I "just" use the System.Spatial.Geography for OData and translate to DbGeography for EF? Something like:
Geography --> OData service --> .net translate --> DbGeography --> EF --> DB
I found another question similar to this one: OData + EF. Writing geography types
But there is no answers nor comments there at all. I assume this problem may have some trivial solution I cannot see, or no one has the same issue (hard to believe...)?
Related
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."
Breeze supports inheritance as of 1.3.2. The DocTest unit tests demonstrate TPH, TPT, and TPC inheritance, based on an Entity Framework server. I am trying to create a similar data service, with similar type inheritance, e.g BankAccount as a subtype of EntityBase, but using MongoDb in the server instead of EF. So I'm loosely following the Zza sample (except not using Angular.js).
The Zza sample does not use inheritance, and it uses a basic JSON format for its metadata. When I fetched the metadata from the DocTest
http://localhost:45678/breeze/inheritance/Metadata
it appears to be in a different format (JSDL?), so I'm stuck with trying to come up with an equivalent JSON format. Initially this looks like adding "abstract": "true" to my base type in the metadata and "baseType":"EntityBase" to derived types.
Is there any reason to think this won't work without EF? And any reason to prefer TPH (Table Per Hierarchy) over TPC (Table Per Class), for example?
The Breeze client doesn't care if the backend is EF or Mongo, and inheritance is supported for either. What is different between Mongo and EF is that with EF we are able to extract metadata about inheritance relationships from the EF model. This is not possible with Mongo because there is no real metadata about the model stored in the Mongo database. This means that with Mongo you have to create the metadata on the client via Breeze's metadata api. It is completely up to you as to whether and how to create an inheritance structure in the metadata that matches what will be returned from a Mongo query. Take a look at the http://www.breezejs.com/documentation/metadata-by-hand for more information.
I am having trouble getting related entities to be loaded on the client using RIA Services and EF 4.1 with Silverlight.
I'm currently using the Include() method on my DbDomainService with an Expression parameter and am finding that when stepping through my service the related entities are loaded just fine. However, when the Queryable results are returned to the client NO related entities are loaded - they are null. All of my entities are marked with the [DataMember] attribute so I have assumed that it isn't a serialization issue. Moreover, my DbDomainService query method is marked with the [Query] attribute.
I was wondering if there is anything specific that has to be set up on the client when using RIA Services with EF 4.1 code first? I must be missing something, but I'm not sure what.
Any help would be appreciated.
Thanks,
sfx
While you may have used the .Include() in your service call, you also have to add the [Include] attribute in the metadata class that is also created.
The .Include() statement tells EF to generate the SQL necessary to retrieve the data, while the Include attribute tells WCF RIA Services to make sure the Entity Class is also created on the client.
Once the data arrives at the client, it needs to know what type of structure to put it in as well.
HTH
Is it possible to have a generic server-side query like the following?
public IQueryable<TContact> GetContactsOfType<TContact>()
where TContact : Contact
{
return ObjectContext.Contacts.OfType<TContact>();
}
I want RIA to recognize and regenerate for me this query at the client project.
Note: Contact is an abstract class that has some subclasses. I'm using Entity-Framework generated EntityObjects.
The error I get when I'm trying compile: Type 'TContact' is not a valid entity type. Entity types must have a default constructor.
By default WCF RIA Services does not expose generic domain service methods for the client to call. RIA is strongly-typed to make it easier to reason about the behavior.
But there seems to be a workaround with defining your on DomainOperationEntry and a custom DomainServiceDescriptionProvider. Colin Blair posted an answer here. That seems to match what you are expecting.
Update: I tried what you want im my silverlight project and defined a generic query method on my domain service. The project compiles successfully but the generic parameter is ommited on the client side.
Instead, I would suggest to use Text Template of EF generator to create RIA Services operations for every entity. And use a pattern of name like how RIA Services uses "Get" <Type> Query, and other methods.
This question is an extension of another question, but I think it warrants its own thread. See See Silverlight Question
I have a stored procedure (SQL 2005) that returns a dynamic data set (different columns/schema) each time it is called.
I want to consume this in Silverlight 3.0 so I need to somehow wire this up using Entity Framework and RIA Services. I also need this to be Bindable (Silverlight Grid) so I need these dynamic columns to be accessible via properties (grid limitation). Any ideas?
In the currently shipping version of the Entity Framework, the only type of stored procedures you can map are those which return entity types. The mapping is done, generally, before you compile, although it seems at least theoretically possible to generate Entity Framework metadata at runtime.
Therefore, I see a few choices.
Give up on the whole idea of consuming a procedure which does not return a defined schema. You will never be able to map such a procedure before you compile.
Dynamically generate EDMX at runtime in order to map an entity type to the expected output columns of the procedure before you invoke. Note that the current version of the Entity Framework is a bit finicky about the columns a procedure returns; you can find documentation about this on MSDN.
In .NET 4.0, there are new features which allow you to inform the Entity Framework about your client schema at runtime without having to generate EDMX first. You might be able to leverage these features in order to map some entity type to the expected output columns of the procedure.
Again, in .NET 4.0, there may be support for procs which return scalar values. I can't remember if this is the case or not.
You can always get a standard database connection from the entity connection and execute the procedure directly, using regular SqlCommands. Unfortunately, this makes your code database-provider-specific, but it may be the simplest solution to your problem. Indeed, using such a procedure at all is already database-server-specific.
You might use a WCF web service wraper for accesing your SP and use the WCF service as data source Brad Abrams has a way to do that on his series of articles on RIA Services