Major improvements and fixes to the C++ OData client library, see below:

[PBRCW]

OData changes:

• Implement log option for http trafic via a callback
• Access to the http headers of a regular message and the $metadata
• Use of _XPLAT() macro instead of the U() macro, allowing the define of U() to not be present if it disturbes
• Naked arrays are allowed
• Collections may legally contain entities, not just primitive or complex types
• Implement open property types
• Implement proper handling of namespace aliases
• Remove the model of this instance from the model cache and the instance on request
• Suppress the output of @OData.type in requests. This is a WAR for TM1 servers that will unjustifiedly choke on such annotations!
• Search query available
• Update an array of values
• Strings can alternatively be a string_t or a ::boost::flyweight<sting_t>
• shared_ptr can be instanciated by make_shared or new
• Fix: Corrected broken overload of what()
• Fix: Missing const added in nemerous places
• Fix: Corrected some typos in the source
• Implement return value of call available
• Fix: Typos in code-generation.h that prevented compilation
• Extended number of parameters from 6 to 12
• Completed operations according to the OData standard
• Implemented the operators of the open property map
• Support VS 2017 and 2019
• Removed warnings to improve code quality
• Added @odata.bind
• Numerous small improvements and fixes

TODOs:

• Make base class of types instanciable (currently not possible due to an abstract class but desirable)
• Implement OData type stream (currently not implemented and an atempt to do so causes a compile error)
• Still large memory consuption if types are complex and there are a lot of them. This is due to the many(!) nullptrs that could be present
• Test not checked for compilability and correctness after changes
• Do checks for compilation under VS 11 and VS12 if desired and make source code compile under those
• shared_ptr of flyweight is of course redundant, so make the strings not use shared_ptr anymore

[mikepizzo]

@PBRCW -- Thanks for your contribution!

As you can see, it's been a while since we've introduced changes to this repo, and some of our backend build processes will have to be resurrected to get out an official build.

Still, I would very much like to take your contributions and support others that may have interest in this project.

We have moved some of these projects (like RESTier, ODataConnectedServices, ODataModelBuilder) to .NET Foundation in order to better engage with the community. If this repo is important to your scenarios, and you anticipate continuing to participate, we can look at moving this to .NET Foundation and making you a moderator. -- LMK your thoughts!

[PBRCW]

Hello Michael, The background: I needed a C++ solution for REST/OData an this library was the only one I found. So I took this and after some fiddling I found that it’s unfortunately rather buggy and some features are not implemented. So over time I fixed bugs, extended the library as needed and implemented missing features. In my case this library is used for a C++ application that connects to an IBM TM1 database using a RESTful API and OData. See https://www.ibm.com/support/knowledgecenter/SSD29G_2.0.0/com.ibm.swg.ba.cognos.tm1_rest_api.2.0.0.doc/tm1_rest_api.html I’m however leaving the company I’m currently working in to end of Jan. So there’s two things I have to do: * Change my email address on github so that it’s pointing on my private address (as I will or course no longer be reachable via my company address) * Thinking about whether I will like an find the time to work as a maintainer of this library privately I must say I don’t see much sense in converting that to a .NET library, or what do you suggest? You already mentioned RESTier, etc. who already do serve this purpose in .NET. What reason is there to have this library as well in .NET? Or do I get something wrong here? Do you mean just putting it on .NET Foundation but keeping it a C++ project? More precise and again: I needed a C++ solution (namely a none gc solution) and this is the only one I found. Whereas I’m meanwhile tempted to say in the state that before my changes it was more like a POC than a solution. It still is very clumsy regarding e. g. its maintenance. This is due to much functionality realized via C’s pre-processor, even templates, and this combination makes it very(!!) hard to debug. Also the code generator who should be able to read the $metadata of some service and create classes from it is still buggy and doesn’t work as intended, name clashes are e. g. one problem, types that aren’t yet supported (but of course may be in the $metadata) is another one that makes it stumble. I ended up for the time being ignoring the code generator and making several files defining the classes that depict the $metadata from the server manually. So there’s work left to do! Also the github page https://github.com/OData/odatacpp-client is in a lousy state, most if not all links result only in a 404. The following things are to be checked: * What do have the client ant the server library (https://github.com/OData/odatacpp-server) in common? My impression was that it shares quite some files but I didn’t take a closer look. My changes of the client side surely lead its code a bit away from the server. The question is, can and must it be that way or could it be avoided? Keeping the identical files identical would be my preference but this is a topic still unclear. At least the server seem to be a bit(!) better maintained, the last commit is “only” four years old and at least the links aren’t broken. But there is no official release as well. * The client library in the optimum case should support all compilers and options Casablanca does as well. Anyway I assume this is currently not the case. However things introduced in C++ recently (like variadic macros) could trim down the code a lot and make it better maintainable, making it highly desirable to use that. Unfortunately older version of VS don’t implement that features, so as long as these are supported the code stays even clumsier that it needs to. * Does it really make sense to convert this library to a .NET version or shall it stay a C++ solution? * Let’s assume I’d become the maintainer, who does the testing with older compiler versions and other destination platforms? I have neither old VS versions nor any kind of Apple OS, so I cannot do it. * My time is scarce, I already know that. If I’d be a maintainer it could only be that it’s very little to do, little traffic and a possible lag in the answering of questions. Anything else I will not be able to manage and this does not make sense. It’ll only annoy other developer as well as myself. What do you think? BR Peter Von: Michael Pizzo <[email protected]> Gesendet: Dienstag, 12. Januar 2021 23:52 An: OData/odatacpp-client <[email protected]> Cc: Peter Brockamp <[email protected]>; Mention <[email protected]> Betreff: Re: [OData/odatacpp-client] Major improvements and fixes to the C++ OData client library, see below: (#32) @PBRCW<https://github.com/PBRCW> -- Thanks for your contribution! As you can see, it's been a while since we've introduced changes to this repo, and some of our backend build processes will have to be resurrected to get out an official build. Still, I would very much like to take your contributions and support others that may have interest in this project. We have moved some of these projects (like RESTier, ODataConnectedServices, ODataModelBuilder) to .NET Foundation in order to better engage with the community. If this repo is important to your scenarios, and you anticipate continuing to participate, we can look at moving this to .NET Foundation and making you a moderator. -- LMK your thoughts! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#32 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AID4CAS5PEZTNZZ5U2HZGNLSZTHCNANCNFSM4V55TDJA>. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this mail in error) please notify the sender immediately and destroy this mail. Any unauthorized copying, disclosure or distribution of the material in this mail is strictly prohibited.

[zeldaxe]

Just Learing