[Announcement] ODataLib 6.2.0 release


We are happy to announce that the ODL 6.2.0 is released and available on nuget along with the source code on codeplex (please read the git history for the v6.2.0 code info and allprevious version). Detailed release notes are listed below.

Bug fixes

Fixed a bug for parsing $it in UriParser.

Improved the JSON serialization performance for unindented format.

New Features

  • Model Enhancement: ODataLib & EdmLib now support complex type inheritance. A complex type can now inherit from another complex type by specify the baseType.
  • Model Enhancement: ODataLib & EdmLib now support open complex type. This feature allows clients to add properties dynamically to instances of this type. The added properties could be a primitive type, a complex type or as complex as an open collection type.
  • Client Enhancement: OData Client now supports property level change tracking for PATCH. If you turn on this feature, the client will only include the updated property in the PATCH payload. If you are building client with massive update, you will find this feature very useful.
  • Client Enhancement: OData Client supports overriding the property name in metadata in proxy classes. e.g. you can use lower-camel naming convention in your client talking to a Server in Pascal naming convention.
  • New APIs: ODataLib support generating ServiceDocument from EdmModel directly by an new extension method GenerateServiceDocument().

Known Issues

  • Type casting for complex type in $filter and $select is not supported.
  • Reading individual property of derived complex type directly by OData Client is not supported.

Call to Action

You and your team are highly welcomed to try out this new version if you are interested in the new features and fixes above. For any feature request, issue or idea please feel free to reach out to us at odatafeedback@microsoft.com.

Thanks,

The OData Team

Comments (6)

  1. Onur Gumus says:

    Thank you for new release, however I wasn't much happy about the client itself, since it makes the same mistake as other abandoned tools like RIA services, Linq To Sql , TypedDataSet etc. It relies on code generation. While code generation can be handy when third party have no prewritten classes, often  we want to make use of exactly same entities from server to share code. And those entities can also have getter only properties for example. I am an avid nhibernate user and unfortunately I find odata geared towards Entity framework. And while entity framework is a great ORM it is quite inferior in terms of feature parity and modeling real world domains. To sum up I am developing a OData Client , it is very alpha is but it can do proper CRUD with link as it is now. It also have nhibernate style dirty tracking, no need to SetLink AddLink methods at all. I haven't written a full demonstration but here you can have some idea about what is supported:

    fodatac.codeplex.com/…/latest

    The commented code also works.(though those tests rely on my own domain I haven't published yet. I will publish more through tests soon)

  2. Yi Ding - MSFT says:

    @Onur Gumus    Tue, Apr 15 2014 3:12 AM

    Dear Onur,

    Thank you for your advice.

    The OData client developing experience doesn't necessarily rely on the code generation. OData Client Code Generator is only an extension of Visual Studio which provides SDK level client experience for developers who wants easy adoption and quick reference of OData services without having to read through the metadata document themselves and hand-writing reference classes. You can also write an OData client solely depends on the ODataLib itself.

    We have to admit that there are few OData client samples or documentations about how to build a client only using ODataLib without code generation. Our team does have plan to invest resouce into building OData .NET library sample services and codes and hopefully they can serve as reference to share with OData .NET developers about the good practice of building OData services and clients using different levels of libraries and tools. The sample clients will absolutely include a .NET client based on code generator and a client based on only OData core libraries with document inline. Good news is that the above mentioned work has already begun.

    We are very happy to hear about the client that you're developing. It is indeed good news for the OData ecosystem. I would recommend that you apply for publishing this stack onto the OData.org, probably in the Ecosystem section of the website. You can also apply for a contributor account to draft a blog post there to share with OData developers about your client and your thoughts when developing it.

    Best,

    Yi

  3. Bernhard says:

    Dear OData Team.

    I tested the 6.2 as i did with the previous versions with a small silverlight client and a web api server.

    I always end up with an ArgumentException at EndExecute (since it is silverlight, i have to use async) at the first query. The same code (but synchronous query aka ToList()) works fine with in a wpf client.

    It is a simple query – no expand, no filter, no sort statements…

    I used fiddler to check for traffic – there is none.

    I did not use the code generator to create the entity classes, i used my own.. (poco)

    The same code (client side) used to work with odata 1-3 libs.

    Could you please point me in the right direction where to find some information?

    Is there a bug tracker / forum / other community site for odata libs?

    Best regards,

    Bernhard

  4. Michael says:

    Hi, Bernhard, is your WebAPI server is a OData V4 version or V3 server?  V4 libraries are not backward compatible with V3.  We made a conscience decision to make V4 libraries incompatible due to V4 changes.

    Michael

  5. Greg A. Scull says:

    This is great news,  I'm working with v4 now and I am wondering when we will see v4 support in the ODataLib for Windows Phone 8.1?

  6. Bernhard says:

    @Michael

    Thanks for your reply.

    The test application uses a V4 WebAPI server. I did some tests with client libs (v4) and WPF and it works.

    The error resides in silverlight client libs V4.

    The error orrures before any data is sent to the server. I used fiddler to check..

    I use silverlight client libs v1-3 and a wcf data services server in a real word project and took my entity classes and query code from that project. Therefore I'm pretty sure i did not misuse the client api…

    I am very well aware of the gap between v1-3 and v4..

    I'd love to see a sample application with a silverlight client that uses v4.

    Best regards,

    Bernhard