Swagger-codegen: [CPPREST] Arbitrary object type results in a compilation error (missing Object.h)

[frol]

Description

Using Codegen on the swagger specification file containing properties of the arbitrary object type results in the following compilation error:

.../model/Inline_response_200.h:25:10: fatal error: Object.h: No such file or directory
 #include "Object.h"
          ^~~~~~~~~~

Swagger-codegen version

I am using the master branch, but I believe that the issue is there from the initial introduction of CPPREST generator.

Swagger declaration file content or url

swagger: "2.0"
info:
  title: "title"
  version: "1.0.0"
paths:
  /pets/:
    get:
      parameters:
      - name: "offset"
        in: "query"
        required: false
        type: "integer"
      responses:
        200:
          description: "successful operation"
          schema:
            type: "object"
            properties:
              extra_info:
                type: "object"

Steps to reproduce

Just run the generator and try building the module:

$ mkdir build
$ cd build
$ cmake -D CPPREST_ROOT=/usr ../
$ make -j 8

Suggest a fix/enhancement

It seems that there should be Object.h implementation (it seems that the standard hash map can be used here).

[stkrwork]

I'll look into this.

[stkrwork]

I am not sure if the creator of this generator expected the person generating it to write the Object.h themselves, because there is also no mustache file available for it.

This problem also seems to be present in Restbed generator, pistache generator.

@sebymiano @wing328 @ravinikam

[frol]

write the Object.h themselves

Given that the Object should represent arbitrary data, there is no point in different implementations for it. It just needs to implement a hashmap... My C++ skills are limited, but I can help with testing...

[ravinikam]

@frol do we really need Object.h? I think we don't . We are not using it. Let me try with your specification and see why its getting added to import in your case.

[ravinikam]

The reason it expecting Object.h is definition of extra_info in specs is incomplete and hence codegen not created separate .h and .cpp files for that object. When we define any object (leaf one) we usually have primitive properties at the end and thats what I think is expected by creator here (and I am agree with it too). Same reason we don't have any includes with object.h in our project since all our leaf objects are holding primitive properties. So I don't think we need to add Object.h. Please correct me if I am wrong.

@frol I think fix for you would be adding other than object type property to extra_info.

@stkrwork @wing328 @sebymiano

[frol]

@ravinikam My spec is valid: https://stackoverflow.com/a/35791870/1178806, and it works as expected with Python and JS generators.

[ravinikam]

@frol I agree, same specification will work for Java as well since java have class called Object to hold values if you don't know which datatype to use. Python, JS, Java have built in support for Object, but same is not there in Cpp. So as far as I know Cpp don't know how to hold values for type "Object", unless we define what data structure needs to be used.

@wing328 @stkrwork

[frol]

@ravinikam there is cpprest::json::value type, which can hold arbitrary data...

[jmp75]

Any update on this issue?
I bumped into the same issue with the Senaps Web API. Draft exploratory notes there.
The API spec has quite a few type: "object" in the definitions.
I have a fair bit of C++ know how but little in the way of Web APIs and swagger. Will see if I can figure out something.

[ravinikam]

We can go with @frol suggested approach of using cpprest::json::value for leaf object since this is cpprest codegen and not just cpp. @wing328 @stkrwork are you ok with it? @jmp75 @frol please submit solution if you have time to contribute.

[wing328]

I'm ok with that to move forward by at least trying something out.

[stkrwork]

If it works well afterwards, yes.

[jmp75]

@ravinikam I am not competent enough in this technology for authoring/submitting something on my own, I think. Too much partial second guessing. I got something compiling by addressing compiler error, basically adding empty methods to a manually written Object class.
Happy to help with road testing something however.

[frol]

@ravinikam I don't have time to work on the C++ client at the moment, sorry.

[wing328]

I don't have time to work on the C++ client at the moment, sorry.

@frol that's ok. Let's see if someone from the community can spare some time to work on this.

[fvarose]

Hi folks, we've come across this problem as well. I will submit a PR hopefully today with a simple fix that solved it for us.

[fvarose]

Sorry all, false alarm I'm afraid. I opened a PR (see #6905) but after looking in more detail it turns out we do still require an Object class that implements the ModelBase for arbitrary map-like objects.
I will hopefully get time to work on this soon.

[wing328]

@fvarose thanks for working on the fix and the update.