Does not support OData parameter "$count".
https://www.odata.org/getting-started/basic-tutorial/#count
It is very important parameter which helps to reduce time for requests.
Moreover, it should be supported if you declare that you are working on an OData protocol.
Requests:
https://my.domain.com/odata/Priority/tabula.ini/demo/DOCUMENTS_D/$count
https://my.domain.com/odata/Priority/tabula.ini/demo/DOCUMENTS_D?$count&$filter=CDES eq 'Some text'
(As usual) Return incorrect "500 Internal Server Error" error.
Is this issue are common for whole Priority REST ?
When you plan to add support of "count" parameter ?
Indeed the $count parameter is not implemented.
It is not mandatory by the Odata protocol specification to support the $count parameter
(on the Minimal and Intermediate Conformance Levels).
Maybe you can use $top parameter in some cases to limit the size of the result.
Regarding the 500 Server error, I suggest you add to the web.config file
the line
<customErrors mode="Off" />
in the system.web section.
Then you may see a more informative error.
Related
Is there a way to specify that I only want to return the first record (or last) of a expanded set of child records using odata?
http://myurl/odata/ParenTable?$count=true&$filter=(Id eq 123456)&$expand=ChildTable($orderby=AddedTimeStamp desc;$top=1)
This is what I am attempting but it returns the message
The query specified in the URI is not valid
Your URL convention is compliant to OData v4 for the behaviour you are expecting.
11.2.4.2.1 Expand Options
The set of expanded entities can be further refined through the application of expand options, expressed as a semicolon-separated list of system query options, enclosed in parentheses.
Allowed system query options are $filter, $select, $orderby, $skip, $top, $count, $search, $expand, and $levels.
But there are older versions and proprietary implementations that are known to not support all or in some cases any of these options like filtering or limiting ($skip,$top) expressions within the $expand query option.
.Net implementations do not support $search OOTB, the API author must manually implement the query option.
That specific error is generally an indicator that the path component, not the query is invalid as most OData runtimes will return more descriptive error response when the resource or collection was correctly resolved but the query could not be parsed or executed. In this case I suspect you have anonymized the path, so we can only speculate, for instance there is an obvious potential typo in the documented path,
there is a 't' missing have you tried:
http://myurl/odata/ParentTable?$count=true&$filter=(Id eq 123456)&$expand=ChildTable($orderby=AddedTimeStamp desc;$top=1)
or is the resource pluralised:
http://myurl/odata/ParenTables?$count=true&$filter=(Id eq 123456)&$expand=ChildTable($orderby=AddedTimeStamp desc;$top=1)
http://myurl/odata/ParentTables?$count=true&$filter=(Id eq 123456)&$expand=ChildTable($orderby=AddedTimeStamp desc;$top=1)
You should include an example of the URL that does work, try without the $top and without the $orderby clauses within the expansion clause. We need to eliminate the errors related to a bad path, vs a bad query.
If you do this via Postman, you can then update your question and post the entire response content.
Both the current ASP.Net and ASP.Net Core implementations do support this, if you are the author of the API please include your controller implementation and the version of the framework you are using so we can assist in greater detail.
An Alternative
If your API does not support this, then given that you are limiting to the $top=1 you could invert the request and use the Child collection resource instead:
Assuming that ~/ChildTable is the route to the ChildTable referred to in your example expansion
http://myurl/odata/ChildTable?$filter=ParentTable/Id eq 123456&$orderby=AddedTimeStamp desc&$top=1&$expand=ParentTable
While trying to access the above odatav4 link with $apply query it shows an error as
"The query parameter '$apply' begins with a system-reserved '$' character but is not recognized."
but works if (apply) used instead of ("$apply")
https://services.odata.org/V4/Northwind/Northwind.svc/Products/?$apply=groupby((UnitsInStock))&$count=true&$top=1000
service link
I can't find the reason why the $apply is not working, since it was working previously
That service is an older implementation of WCF Services that is only partially compliant with OData v4 query syntax and as such does not support $apply.
but works if (apply) used instead of ("$apply")
You will notice that although there is no error, the query is returning the same results as if you had not included the $apply query option at all.
Your query syntax should work on a properly compliant API though, for instance you can use the TripPin service:
this query itself is not very useful, but it demonstrates the syntax
https://services.odata.org/TripPinRESTierService/People?$apply=groupby((LastName))
The following URI triggered an error in the public OData service:
http://services.odata.org/V4/Northwind/Northwind.svc/Suppliers?$filter=Address eq '<A'
Entity type Supplier contains property Address of type Edm.String. So, the value of Address may contain any UTF-8 character from the definition (see section 6. Primitive data types).
The server responds with:
Runtime Error: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons).
Is the there something wrong with this URI or it is really a problem on the server side (e.g. inappropriate parsing of the $filter query option)?
You should encode your query URL, e.g. with help of
http://prasannaadavi.com/2014/06/handling-special-characters-in-odata-queries.html
How are special characters handled in an oData query?
In your special case you should try encoding "<A" with "<A"
--> found in https://web.archive.org/web/20150101222238/http://msdn.microsoft.com/en-us/library/aa226544(SQL.80).aspx)
There was a change "3.2.10 Pruned: URI Literal suffixes for numeric types" in OData v4 specification. Now OData.Client for OData v4 sends double literals without these sfuffixes, but we need them for our proejct to work correctly. I can't find a legal way to turn back this OData v3 behaviour, except brancing OData.Client. Does anybody know a way to change this behaviour using the generated T4 client proxies or something?
It can't fallback to old numeric format (with suffix) . You may consider hooking up DataServiceContext's SendingRequest2 event, modify the request URL to meet the server side's expectation.
However, the server side should have numeric value's type information (either in model or in CLR types) just like client has for building the request, so theoretically, suffix is unnecessary.
I am trying to fetch data from a service that i donot know much about.
So i got its url like
http://ABC.com/ABC.svc
so i thouhgt to get metadata as
http://ABC.com/ABC.svc/$metadata
it gives me:
<EntityType Name="E1">
- <Key>
<PropertyRef Name="E1k1" />
</Key>
< Property Name="E2" Type="Edm.String" Nullable="true"
m:FC_TargetPath="SyndicationTitle" ..>
<ComplexType Name="OptionV1">
<Property Name="Value" Type="Edm.Int32" Nullable="true" />
... and a lot more.
How do i find out what should come next to ABC.svc/???
I want to write queries to access data. Can smebody point me to what should be my next steps?
and any learning resource on this query generation from metadata would be hlpful.
Thanks
There are two ways:
1) Using the service document. Navigate to the ABC.svc, that should return a service document, that is an ATOM Service payload which contains the names of the entity sets available from the service. For a sample of such you can go to http://services.odata.org/OData/OData.svc/. This should return a document with three collections (Entity sets). The href attribute is a relative URI to the entity set (relative to the xml:base which is usually the base of the service). So if for example your service has an entity set E1Set, then typically the address of it would be ABC.svc/E1Set.
2) Using the $metadata document and assuming the usual addressing scheme (note that this usually applies to the service but it doesn't have to). The $metadata document will define entity sets. Each of these is usually exposed by the service and typically follows the addressing scheme of ABC.svc/EntitySetName.
Once you navigate to the entity set, you should get back an ATOM feed with the entities in that set. The $metadata will help you recognize the shapes of the entities and the relationships.
Some services also have service operations or actions and so on. These are not exposed in the service document #1. Instead they are only visible in the $metadata as FunctionImport elements. They usually follow the addressing scheme of ABC.svc/FunctionImportName. But note that you might need to know something more about the service operation to be able to invoke it (what HTTP verb to use, what are the parameters, what it will do, and so on).
LinqPad provides a very simple means for getting started with OData services (assuming some familiarity with LINQ). If you will primarily be primarily consuming this application from .NET, I'd recommend starting with this application. You point it to the $metadata endpoint and it generates proxy classes which allow you to work with the OData service much like you would in a plain-old-.NET-app. On the Results Log tab, it will output the URL used to query the OData service, which you can then pick up and tweak in Fiddler. (For more about how to use OData + Fiddler, see this blog post.)
If you'll primarily be using the OData service from JavaScript, you might want to start by understanding the URI conventions better or by playing around with data.js.