We are using the ADO.NET Data Service Provider Toolkit to implement a custom OData service endpoint running inside SharePoint 2010 (using .NET 3.5).
It appears that by default Edm.DateTime is marked as Nullable="false" when generating the metadata for the service endpoint:
<Property Name="DATE" Type="Edm.DateTime" Nullable="false" />
Is there a way to change this setting for DateTime properties that can be NULL?
The same seems to be true for Edm.Boolean as well as some of the numeric types.
If the type of the property is Nullable, then so will the OData property.
In this case instead of DateTime, the property needs to be DateTime? (nullable).
Related
I am using postgres/postgis as db and Nhibernate as ORM on a C# project.
This is the first time I try to map postgis to a .Net application. My setup uses NHibernate version 4.0.4.4000 and NHibernate.Spatial.PostGis 4.0.4.4000 (with Npgsql version 3.0.5)
I followed this tutorial in order to set up the mappings, so I have:
in the web.config
<property name="dialect">NHibernate.Spatial.Dialect.PostGisDialect,NHibernate.Spatial.PostGis</property>
for the nhibernate configuration I added
cfg.AddAuxiliaryDatabaseObject(new SpatialAuxiliaryDatabaseObject(cfg));
my xml mapping file has the following mapping:
<property name="Geom" column="the_geom" type="NHibernate.Spatial.Type.GeometryType, NHibernate.Spatial" />
also tried using PostGis namespace in the mapping:
<property name="Geom" column="the_geom">
<type name="NHibernate.Spatial.Type.PostGisGeometryType, NHibernate.Spatial.PostGis">
<param name="srid">3006</param>
<param name="subtype">POLYGON</param>
</type>
</property>
and my model class has the following property
public virtual IGeometry Geom { get; set; }
Now when ever I fetch any of the geometries the property Geom is null.
In the logs I don't get exceptions nor error messages.
I don't know what else to try.
In this question, using MS sql server, he got it working because he figured out that hist current dll (Microsoft.SqlServer.Types.dll) and the required one supported different versions of Ms sql, so mapping that dll to an older version fixed the problem. Could that be the case here? how/what can I try?
I have also looked at this post where it worked for him by defining his own UserTypeConvention but I don't have "UserTypeConvention" defined, so it does not work for me.
I have tried posting this question at gis stackexchange with no results, so I am trying here.
The issue here was that the version of Npgsql which I was using (version 3.0.5).
There seems to be a problem with that version and does not handle Geometry correctly and so that is why I get null.
Downgrade to version 2.2.7 of Npgsql and it works.
A second problem I found was that I was not able to do any inserts to tables which have Identity columns, so I had to change the dialect, following this link it helped me.
I also need to state that I could not have solved this if it was not by the help of rsquare who is the one which actually found this issue between nhibernte and version 3.x of Npgsql.
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...)?
As suggested here and here, I should be able to apply tolower to do a case-insensitive field match with a REST call to the OrganizationData.svc endpoint.
Here's my GET request:
/XRMServices/2011/OrganizationData.svc/ContactSet?$filter=tolower(EMailAddress1) eq 'me#awesome.com'
And I get the following result:
<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<code>-2147220715</code>
<message xml:lang="en-US">
Invalid 'where' condition. An entity member is invoking an invalid property or method.
</message>
</error>
What am I doing wrong? How can I do a case-insensitive match on the EmailAddress1 field on the Contact entity using the REST endpoint?
(Note: I know I can change the SQL Server collation to case-insensitive but I need this to work for Dynamics online as well).
SOLUTION
So it looks like tolower is not supported at all in the OData implementation for the Dynamics REST API. If you need to do a case-insensitive match, the only way I found is to change the SQL Server database collation in an on-premise install.
For Dynamics online, you'd probably need to write a plugin that fires on entity create/update and converts the field to lower-case.
You would not be able to do that. By default all information (and in CRM Online) as well is stored in case-sensitive DBs so you just would not be able to do case insensitive search.
I am attempting to add a new EF4 POCO to an existing solution. I am getting following error, and when I look at existing POCO already created in the solution I cannot work out how the link is made between the POCO and the table.
Mapping and metadata information could not be found for EntityType 'XXX.Run'.
Here is an example of one that works in the solution and I cant figure out why:
namespace XXX.AnotherPlace.Products
{
public partial class Product : BaseEntity
{
When I look at the edmx file there is no mension of this class, just other classes in namespace that don't seem to exist:
<EntitySet Name="Product" EntityType="XXX.Store.tbl_Product" store:Type="Tables" Schema="dbo" />
<End Type="XXXX.Data.Product" Role="Product" Multiplicity="1" />
What am I missing, there there some convenstion that need to be followed? How do I link a table with my own POCO
Your entity needs to exists within the edmx. The conventional approach is to produce the entity within the EF design surface then use the T4 POCO template to produce your classes. Assuming the solution used the templates you can add the entity to the design surface then rerun the custom tool from the property page for the T4 generated code.
I am using EF4 with Visual Studio 2010. I have a SQL database already created and all my columns are documented with the Description property in SQL management studio. When I create the edmx in Visual Studio, how can I make it read those descriptions and use them to add comments to my generated classes? I know I can use the Summary and LongDescription in the edmx properties but I'm looking for a way to do this without having to copy and paste every description.
Thanks!
There is a feature request for this. Feel free to add your votes to help make this available in the future:
Retrieve the SQL Descriptions in Entity-Framework feature request
Huagati has some great tools for working with EF and L2S. One of the features is updating the EF documentation based on the SQL database:
Huagati website
From the website: Update ADO.NET Entity Data Model documentation from database retrieves free-text table and column descriptions, and index definitions from the database and updates the xml documentation fields in the EDMX designer with the descriptions.
It seems they look for these fields in the database and then update the model XML directly. Probably someone could create a VS Add-In that would do the same without the price if this is the only feature you wanted. I'll add this to my list of "future" projects (though I never seem to find time for these!).
Hope that helps!
I've been looking at ways of hacking something together to populate the edmx with the meta data from the database.
The summary and long description edmx properties are stored in elements under the EntityType element.
<EntityType Name="EntityName">
<!-- Without this element classes are typically generated with
"No Metadata Documentation available." -->
<Documentation>
<Summary>Entity Summary</Summary>
<LongDescription>Entity Long Description</LongDescription>
</Documentation>
<Key>
<PropertyRef Name="Id" />
</Key>
<Property Name="Id" Type="String" Nullable="false" MaxLength="25" Unicode="false" FixedLength="true" />
<!-- Lots of other properties -->
</EntityType>
The relevant section of the edmx file, the Store Schema Definition Language (SSDL), is created by System.Data.Entity.Design.EntityStoreSchemaGenerator.GenerateStoreMetadata(). Or at least this is the case with EdmGen.
I'm going to see if the EntityStoreSchemaGenerator.StoreItemCollection can be modified before being used by EntityStoreSchemaGenerator.WriteStoreSchema(...) to output the XML.
Update
Well that was annoying. System.Data.Metadata.Edm.Documentation is sealed and only has an internal constructor. Both properties of interest can only be set internally as well.
So it seems like a dead end approach.
I don't know that the designer itself has any extensibility points. However, once the Summary and LongDescription fields are populated in your edmx file, those value will remain there, even if you make other changes or re-updated your model from the database. Unless you delete a table and re-add it, those values will remain populated.
So you could either just copy and paste them all in one at a time (how many tables are in your model? This goes quicker than you think), or write a program to extract the info from your database (using SQL SMO or something), and have that program edit your edmx file, populating the Summary and LongDescription fields (make a backup of your edmx each time you try your program -- you don't want to botch your edmx file and have to start over).
If you have large models, and you're making lots of them, writing a program to do it automatically is worth your time. If you've only got a few models, with not too many tables, copy paste it is.
You might want to think about submitting feedback to the Entity Framework team here. Seems like the designer should automatically pick up on the description field from SQL Server. Would make a good feature request.