-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception: Table TestTable not found #6
Comments
Thank you for the report. I tested your service and noticed that comparing to other OData feeds it lacks property m:IsDefaultEntityContainer="true" in entity set definition. I will check the specification, and if there is no requirement for a default entity container, I will make a fix and let you know. |
I have made a small fix in Simple.OData.Client (a package that Simple.Data.OData uses), so now it longer requires m:IsDefaultEntityContainer="true" in the entity set definition. However, it still fails to read TestTable content due to a different problem. If you look at entry XML, here is how it looks: <entry> Note that the "id" is set to "0". But the "id" is the entity key, and according to the schema the key property is DateS, so the "id" should be set to the same value as DateS. Moreover, according to the OData specification, "the "atom:id" element conveys a permanent, universally unique identifier for an entry or feed." Here's an example of entry "id" from a sample service: <id>http://services.odata.org/V3/OData/OData.svc/Products(0)</id> So it seems to me that the entry XML doesn't fully follow OData spec. How did you build your OData service? DId you write your own feed generation code or you used some other tools? |
Hi. I also fixed the IsDefaultEntityContainer in my metadata. |
Hi, I asked Microsoft's Michael Pizzo, and he explained that in V4 the requirements relaxed: "In OData, the entity id is supposed to be a URI that uniquely identifies the entity. In V4 we encourage the use of a URL that can be used to retrieve the entity, but that's not required. The id is opaque to the client and need not contain the key value(s)." So in fact your format is correct according to V4 protocol although it may create problems for some clients (like mine :-)). I will try to make a fix asap, but in the meantime if you want to make it work with current version of Simple.Data OData adapter, you have to changes entity "id" according to the old specs. Here's what you can do.
Have a look at the sample service http://services.odata.org/Northwind/Northwind.svc, in particularly at tables Orders and Order_Details that show both cases. I will leave the issue open and support the latest and more relaxed requirement. But if you want your OData feed compliant with older specs (and supported by more clients), you can change id formatting as I showed. |
Wow... that's a really informative response. Thanks much. |
I modified my odata endpoint to return urls for id's, but I don't think you are parsing dates in uri odata format correctly. ie: |
Thanks, I am will look at it asap. I am planning to release a new version tonight, hopefully this issue will be addressed too. |
Great. FYI, here is a link to some of the primitive data types and how they should be serialized/deserialized in a url: http://www.odata.org/documentation/odata-version-2-0/overview/#AbstractTypeSystem |
I just pushed the version 2.1.0 of Simple.OData.Client that should fix parsing datetime literals. I'll appreciate if you test it. |
dynamic db = Database.Opener.Open("http://nsuli.com/odata3/us/");
|
I have tested against your feed now, and what I see is that you write datetime properties with "Z" suffix, but this is accepted only for "datetimeoffset" properties. If I check the link you sent me, I find the following: DateTime: datetime’yyyy-mm-ddThh:mm[:ss[.fffffff]]’ NOTE: Spaces are not allowed between datetime and quoted portion. datetime is case-insensitive DateTimeOffset: datetimeoffset’’ dateTimeOffsetLiteral = Defined by the lexical representation for datetime (including timezone offset) at http://www.w3.org/TR/xmlschema-2 AFAIK you shouldn't be using "Z" with datetime fields and this is what's causing the parsing error. Can you please double-check this? |
Oops, my bad! Actually I didn't fully merged my changes from a development branch. Now I pushed the version 2.1.1, can you try that? I tested on your feed and it seems to work! |
I fixed the "Z" problem. Your plugin works (before and after my "Z" fix). |
Thanks for the link, it's quite useful. I am planning to replace my internal OData serializer code with ODataLib, but will have to keep home-made serialization until then. Cheers! |
I can't figure out why:
dynamic db = Database.Opener.Open("http://nsuli.com/odata3/us/");
IEnumerable products = db.TestTable.All();
The text was updated successfully, but these errors were encountered: