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.
Related
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...)?
Request: /api/person?$filter Name eq 'John' with server backed up method that
return repo.GetAll().Select(o => Mapper.Map<>PersonDTO>(o));
Only the $filter requests error out with "Where with predicate after a project is not supported" but $top / $skip / $orderby work fine. My guess is, Mongo C# has a bug while generating the query & projects before applying the filter. Instead it should apply filter first and then project. I am using OData 5.2.0-rc1 and Mongo C# driver is 1.7.
Any inputs are much appreciated. Thanks...
That is a limitation in the current implementation of Linq. We are working to correct that with this ticket: https://jira.mongodb.org/browse/CSHARP-601.
However, I'd encourage you to figure out what you are actually attempting to do. Projecting prior to a filter could mean you are filtering on computed expressions, such as adding 2 columns together. MongoDB queries do not support this type of behavior, which is why this is currently disallowed by our linq provider. Aggregation framework allows this to a point, but there are a different set of limitations imposed by the Aggregation framework.
In your particular case, what you are wanting us to do is impossible. You are asking us to know how to create a MongoDB query based on an AutoMapper generated object. This simply impossible unless we (at runtime) read the AutoMapper mapping and apply it to our internal class models.
Based on the recommendation by APIGEE in their RESTful API Design blog post I wish to implement the fields query-string parameter to allow mobile application clients to restrict the content returned from a single RESTful API call. For example:
domain.site.com/rest/accounts/{id}?fields=name,id,age
If the fields parameter is omitted then a complete account resource will be returned. My question is how would I implement this on the server using Jersey (for example). Since Jersey makes it easy to return an Account POJO but I am unsure how to restrict the fields of the resulting JSON object based on the 'fields' query-string parameter.
There's not an automatic way to do it. Your service should load the entire object and then null out the fields you dont' want. Make sure the beans are annotated to ignore null fields in the json serialization and then return the object after you've modified it to remove the fields you dont' want.
I have 3 entities.
PortalRole, Person and PersonPortalRole
PersonPortalRole is a intersection entity to deal with my Many-Many relationship.
I am using JavaScript through a HTML web resource to allow the creation and removal of this entity. I can create new entities by using the REST service fairly easily but I can't find a way of deleting a intersect record (two lookup fields) using the PersonId and PortalRoleId.
Has anyone had any exposure to either deleting a record through REST using the two foreign keys values from a lookup? I was trying to get the object first using a filter but can't seemt o filter using the lookup primary keys.
Was trying something like below which returns 15 entries to then filter the results to get the primary key, and then delete using that key but not sure on the way to do this.
SERVER/INSTANCE/XRMServices/2011/OrganizationData.svc/personportalrolesSet?$expand=Person,PortalRole
Based on that URI, you are interacting with an OData service. OData uses Atom feeds for returning lists of stuff so you will likely find within each <entry> element a <id> element that contains the URL of the resource. If you issue a HTTP DELETE to that URL then your resource will be deleted.
See docs here http://www.odata.org/developers/protocols/operations#DeletingEntries
I don't use the REST endpoint, but there's no way I know of to end a many-to-many relationship except through sending a Disassociate request (or if you have access to the SQL box, direct insertion/deletion in that table). MS has some sample code available that shows how to do this using the REST Endpoint.
I've been following the walkthrough for creating your first WCF RIA Services Application from Microsoft and have encountered a problem when trying to edit and update data using the SubmitChanges() method of the Data Context.
The table being updated has an Identity Specification set in SQL Server 2008 on the 'CourseID' column. However the PRIMARY key is a composite of two other fields.
When using SubmitChanges() the application locks up in the browser an presents an unhandled exception. By handling this exception I managed to get the message: Modifying a column with the 'Identity' pattern is not supported. This is referring to the 'CourseID' column.
Turning identity specification off solves the problem, but I need the auto-incrementing ID. In what way isn't this supported. Or where am I going wrong?
As a comment above specifies you need to set the StoreGeneraratedPattern to "Computed".
While you can change this on the Model Designer which changes the value in the CSDL. However for it to work the value also has to be changed in the SSDL. The only way to change this is to modify the XML by hand.
Keep in mind various things like "Update model from database" will regenerate the SSDL... so you have to reapply you changes.
There is a workaround for this issue: add the [RoundtripOriginal] attribute to the corresponding property in your entity's metadata class.
See Jeff Handley's response in this Silverlight Forums discussion:
WCF RIA Bug: Changes include "Identity" column DomainDataSource( "Indentity" column no modify), WCF RIA does not support
The database structure is at fault here.