I'm calling a bound function. It works fine when I request the entity by its key:
/MyEntity(1)/MyFunction
However, I have to request the entity by MyField, which is unique but it isn't the key:
/MyEntity?$filter=MyField eq 1
What is the syntax for calling a function in this case? Just adding "/MyFunction" to the end doesn't work:
/MyEntity?$filter=MyField eq 1/MyFunction
This is not surprising, since $filter actually returns not an entity, but a collection of one single entity. I guess, basically what I need is to get the first entity from the payload.
I've looked through the documentation, but couldn't find the answer, it seems I'm missing something obvious.
Related
This is from the category "unexpected behavior" - take the following query (you can paste it in Graph Explorer):
https://graph.microsoft.com/v1.0/users?$filter=idc eq 'test'
This returns status code 400 and "Property 'idc' does not exist as a declared property or extension property." Which is a sensible and understandable response.
Now, if try to $select this property:
https://graph.microsoft.com/v1.0/users?$select=idc
I get a result I totally don't expect:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(idc)",
"#odata.nextLink": "https://graph.microsoft.com/v1.0/users?$select=idc&$skiptoken=cut",
"value": [
{},
{},
...
{}
]
}
(a list of empty objects; asking for a single user with that invalid property name returns me an emtpy response).
So my question is - why does $filter error out and $select does not? Would there be a way to force $select to error out too? (eg I am using the /beta endpoint and a property name changes - I want my code to fail to find out)
Sorry for the late answer. We had a discussion on this and would love to get some of your thoughts (and the thoughts of other developers). We don't have a clear answer on this yet.
There are 2 schools of thought here:
Make $select and $filter behave consistently when dealing with properties that don't exist.
It's OK for these to differ in behavior, since the caller’s intent when specifying $select is likely different than that of $filter. The service cannot ignore a property specified in $filter because it completely changes the set of objects that are returned. However, $select does not change the set of objects but only drops the properties that are not available. Hence $select and $filter do not need to be consistent.
Thoughts?
Hope this helps,
I've been trying to call a entity, but i'm supposed to call the results from its associated entities. I tried to do it with the following URL:
/sap/opu/odata/XXXXXXXX/SERVICE_NAME/MatnrGetdetailCollection?$filter=IVendorId eq '1701' and ILanguage eq 'P' and IMaterial eq 'M-05'&$expand=MatnrClassGetdetail
I must use the filter because the called function has these mandatory parameters.
Am I making any mistake on the URL or the error isn't there?
In general $filter and $expand can be combined, we use it in our application. Therefore please see Layla's Comment. In addition, you should tell us what the actual error is.
If MatnrGetdetailCollection is indeed an entity set, then the corresponding entity must have a navigation property of the name MatnrClassGetdetail, otherwise $expand won't work.
There is some problem with the URL when you want to go for obligatory parameters. Please pass them as key values in segw and and go for the format I'm sending:
/sap/opu/odata/sap/SERVICE_NAME/EntitySet(keyfield='value',keyfield='value')/?$expand=navigationName
Hello I am trying to execute a query using breezejs 1.3.4 . My query is the following
function getContacts() {
var query = breeze.EntityQuery
.from("Contacts").where("Desc", "startsWith", "P");
return manager.executeQuery(query)
.then(getSucceeded).fail(getFailed);
}
"Desc" is a string property in my "Contacts" C# backend model. Tha problem is that the Query URL is formatted like this .../api/Application/Contacts?$filter=startswith(Desc%2Ctime'P')%20eq%20true
The word time is added before "P" and I get a this exception in the Response
{"$id":"1","$type":"System.Web.Http.HttpError, System.Web.Http","Message":"The query specified in the URI is not valid.","ExceptionMessage":"Unrecognized 'Edm.Time' literal 'time'P''
If in the comparison I use a lower case "p" then the Url is costructed as it should be like this
"$filter=startswith(Desc%2C'p')%20eq%20true` .
I don't have the same problem when using other UpperCase letters of the english alphabet.
Does anyone have an idea what am I missing, I can't figure out why the word "time" is added in that specific query?
Thank you.
We were able to reproduce the problem.
While the exception message is confusing, I believe you might be getting the error because you have not associated that the resource name 'Contacts' with an EntityType of presumably 'Contact'.
What is happening is that when Breeze tries to build the query it will usually use its metadata to correctly format the url query string to send to the server. The critical part of this process involves determining the EntityType associated with the resourceName given in the 'from' clause of the query ('Contacts' in your case). Breeze uses a resource name to entity type map to do this, but if it cannot find a mapping, it will still continue to build the url because we still need to support ad-hoc requests against endpoints for which we have no metadata.
You can update this map yourself via the MetadataStore.setEntityTypeForResourceName method. If you are using the Entity Framework, this map is initially populated based on the EntityType name/Entity Set name mapping that is part of your EDMX model. So in your case you can either modify your EDMX model or call the setEntityTypeForResourceName method directly.
Unfortunately, without the metadata Breeze has to infer the datatypes in the query. So in your case
"Desc", "startsWith", "P"
since Breeze can't determine that "Desc" is a 'string' property of your Contract EntityType it tries to infer the 'dataType' of "Desc" based on the value 'P'. Unfortunately, 'P' is a valid ISO8601 'duration' value ( a way to express a 'Time' datatype), so Breeze incorrectly tries to construct a query string with 'P' treated as a 'Time' constant. This is why your code works with a lower case 'p' ( not a valid duration value).
This inference logic can certainly be improved and we have a fix that will allow us to do exactly that coming out in the next release. However... the better and more general solution to this type of issue is to get the 'resourceName/entityType' mappings correct in the first place.
Hope this helps.
i´m using the Papa's course CCJS code to investigate Breeze.js and SPA. Using this code i´m trying to manage aditional information that cames from server but that is not an Entity contained in the Metadata that cames from EntityFramework.
So i created a NO-DB class called Esto and a Server method like Lookups:
[HttpGet]
public object Informacion()
{
var a = new Esto(....);
var b = new Esto(.....);
var c = new Esto(......);
return new {a,b,c};
}
then in model.js inside configureMetadataStore i call:
metadataStore.addEntityType({
shortName: "Esto",
namespace:"CodeCamper",
dataProperties:{
id: {dataType: breeze.DataType.Int32,isPartOfKey: true},
name: {dataType: breeze.DataType.String}
}
};
and also define in the model entityNames array: esto:'Esto' as an Entity
now in the context.js i load this creating a server side method like getLookups but called getInformacion:
function getInformacion(){
return EntityQuery.from('Informacion')
.using(manager).execute()
}
and then inside primeData in the success method call this:
datacontext.informacion = {
esto: getLocal('Esto',nombre)};
where getLocal is:
function getLocal(resource, ordering)
{
var query = EntityQuery.from(resource).orderBy(ordering);
return manager.executeQueryLocally(query);
}
I get an error in the query contained in the getLocal that states that Can not find EntityType for either entityTypeName: 'undefined' or resourceName:'Esto'.
What i´m doing wrong?
Thanks
You were almost there! :-) Had you specified the target EntityType in the query I think it would have worked.
Try this:
var query = EntityQuery.from(resource).orderBy(ordering).toType('Esto');
The toType() method tells Breeze that the top-level objects returned by this query will be of type Esto.
Why?
Let's think about how Breeze interprets a query specification.
Notice that you began your query, as we usually do, by naming the resource which will supply the data. This resource is typically a path segment to a remote service endpoint, perhaps the name of a Web API controller method ... a method named "Foos".
It's critical to understand that the query resource name is rarely the same as the EntityType name! They may be similar - "Foos" (plural) is similar to the type name "Foo" (singular). But the resource name could be something else. It could be "GetFoos" or "GreatFoos" or anything at all. What matters is that the service method returns "Foo" entities.
Breeze needs a way to correlate the resource name with the EntityType name. Breeze doesn't know the correlation on its own. The toType() method is one way to tell Breeze about it.
Why do remote queries work without toType()?
You generally don't add toType() to your queries. Why now?
Most of the time [1], Breeze doesn't need to know the EntityType until after the data arrive from the server. When the JSON query results includes the type name (as they do when they come from a Breeze Web API controller for example), Breeze can map the arriving JSON data into entities without our help ... assuming that these type names are in metadata.
Local cache queries are different
When you query the cache ... say with executeQueryLocally ... Breeze must know which cached entity-set to search before it can query locally.
It "knows" if you specify the type with toType(). But if you omit toType(), Breeze has to make do with the query's resource name.
Breeze doesn't guess. Instead, it looks in an EntityType/ResourceName map for the entity-set that matches the query resource name.
The resource name refers to a service endpoint, not a cached entity-set. There is no entity-set named "Informacion", for example. So Breeze uses an EntityType/ResourceName map to find the entity type associated with the query resource name.
EntityType/ResourceName
The EntityType/ResourceName map is one of the items in the Breeze MetadataStore. You've probably never heard of it. That's good; you shouldn't have to think about it ... unless you do something unusual like define your own types.
The map of a new MetadataStore starts empty. Breeze populates it from server metadata if those metadata contain EntityType/Resource mappings.
For example, the Breeze EFContextProvider generates metadata with mappings derived from DbSet names. When you define a Foo class and exposed it from a DbContext as a DbSet named "Foos", the EFContextProvider metadata generator adds a mapping from the "Foos" resource name to the Foo entity type.
Controller developers tend to use DbSet names for method names. The conventional Breeze Web API controller "Foo" query method looks like this:
[Get]
public IQueryable<Foo> Foos() {...}
Now if you take a query such as this:
var query = EntityQuery.from('Foos').where(...);
and apply it to the cache
manager.query.executeLocally(query).then(...);
it just works.
Why? Because
"Foos" is the name of a DbSet on the server
The EFContextProvider generated metadata mapping ["Foos" to Model.Foo]
The Web API Controller offers a Foos action method.
The BreezeJS query specifies "Foos"
The executeLocally method finds the ["Foos"-to-Model.Foo] mapping in metadata and applies the query to the entity-set for Foo.
The end-to-end conventions work silently in your favor.
... until you mention a resource name that is not in the EntityType/ResourceName map!
Register the resource name
No problem!
You can add your own resource-to-entity-type mappings as follows:
var metadataStore = manager.metadataStore;
var typeName = 'some-type-name';
var entityType = metadataStore.getEntityType(typeName);
metadataStore.setEntityTypeForResourceName(resource, entityType);
Breeze is also happy with just the name of the type:
metadataStore.setEntityTypeForResourceName(resource, typeName);
In your case, somewhere near the top of your DataContext, you could write:
var metadataStore = manager.metadataStore;
// map two resource names to Esto
metadataStore.setEntityTypeForResourceName('Esto', 'Esto');
metadataStore.setEntityTypeForResourceName('Informacion', 'Esto');
Don't over-use toType()
The toType() method is a good short-cut solution when you need to map the top-level objects in the query result to an EntityType. You don't have to mess around with registering resource names.
However, you must remember to add toType() to every query that needs it. Configure Breeze metadata with the resource-to-entity-type mapping and you'll get the desired behavior every time.
Notes
[1] "Most of the time, Breeze doesn't need to know the EntityType until after the data arrive from the server." One important exception - out of scope for this discussion - is when the query filter involves a Date/Time.
I think that the problem here is that you are assuming that entity type names and resource names are the same thing. A resource name is what is used to execute a query
var q = EntityQuery.from(resourceName);
In your case the "resourceName" is "Informacion" and the entityType is actually "Esto". Breeze is able to make this connection on a remote query because it can examine the results returned from the server as a result of querying "Informacion" and seeing that they are actually "Esto" instances. This is not possible for a local query because Breeze doesn't know what local collection to start from.
In this case you need to give Breeze a little more information via the MetadataStore.setEntityTypeForResourceName method. Something like this:
var estoType = manager.metadataStore.getEntityType("Esto");
manager.metadataStore.setEntityTypeForResourceName("Informacion", estoType);
Note that this is not actually necessary if the resource was defined via Entity Framework metadata, because Breeze automatically associates all EF EntitySet names to resource names, but this information isn't available for DTO's.
Note also that a single entity type can have as many resourceNames as you like. Just make sure to register the resourceNames before you attempt a local query.
does anyone know how to express an OData $filter against a nested property?
for ex. I have the following Atom entry,
<entry>
...
<m:properties>
...
<d:RegardingObjectId m:type="Microsoft.Crm.Sdk.Data.Services.EntityReference">
<d:Id m:type="Edm.Guid">3f3712fd-fc49-e211-8eb8-000c296272c8</d:Id>
<d:LogicalName>new_sportsleague</d:LogicalName>
<d:Name>Boca</d:Name>
</d:RegardingObjectId>
I want to filter for those entries that have RegardingObjectId/LogicalName eq 'new_sportsleague'.
Tried with 'RegardingObjectId/LogicalName' and 'RegardingObjectId.LogicalName' with no luck.
'RegardingObjectId/LogicalName' would be the correct syntax.
For example:
http://services.odata.org/v3/OData/OData.svc/Suppliers
returns two results, whereas
http://services.odata.org/v3/OData/OData.svc/Suppliers?$filter=Address/Street eq 'NE 228th'
returns just one.
I don't see a place in the OData spec that explicitly states whether filtering using properties of a complex value is legal or not, but it seems that WCF Data Services supports it. It could be that other OData implementations don't.
Use following odata API example to access nested properties with filter data
http://192.168.50.152:50086/odata/StationOperationLogs/?$expand=ProductionStation,ProductionStation/ProductionUnit&$filter=ProductionStation/ProductionUnit/Id eq 2