Skip to content
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

[BUG] [cpp-qt5][cpp-qt5-qhttpengine-server] type:string format:byte handled differently by the two generators #1708

Closed
dtucker61 opened this issue Dec 18, 2018 · 6 comments

Comments

@dtucker61
Copy link

Description

I am generating both client and server side code using a same API specification file (see sample file below).
My API spec defines a component of type 'object' that contains a single 'properties' of type: string, format: byte.
When I generate the cpp-qt5-qhttpengine-server code, the model generate contains a private member of type 'QByteArray', and the setter and getter method's parameters is called by reference (const QByteArray &). All good, code compiles.
When I generate the cpp-qt5 client code, the corresponding model generates a private member of type 'QByteArray*' (pointer), and the setter and getter method's parameter is called by address and reference (?) (const QByteArray* &). No good; this code does not compile.

I then compared the mustache files for the two generators. The 'model-body.mustache' and the 'model-header.mustache' in the two generator's template resources are the same.

I then looked into those two mustache files. It appears that the {{datatype}} variable is related to the problem. I think the value of the {{datatype}} variable gets instantiated differently by the two projects, resulting in different code generation.

If I hand-edit the cpp-qt5 generated code and remove the '*', then I can get the code to compile. Note: I also have to fix-up a reference to the m_blob_isSet private data member in the ::asJsonObject() and ::isSet() methods.

Version

I am using VERSION 3.3.4. I downloaded the jar file per instructions on your GitHub page.

The mustache files I am using have been downloaded from your GitHub page.

OpenAPI declaration file content or url

openapi: "3.0.0"
info:
version: 1.0.0
title: Check ByteArray
servers:

  • url: http://localhost:8080
    paths:
    CheckByteArray:
    get:
    summary: Check Byte Array generation
    operationId: list
    tags:
    - Check
    responses:
    '200':
    description: Every things gonna be alright
    content:
    application/json:
    schema:
    $ref: "#/components/schemas/Content"
    components:
    schemas:
    Bytes:
    format: byte
    type: string

    Content:
    type: object
    properties:
    type:
    $ref: '#/components/schemas/Bytes'

Command line used for generation

For generating the server:
java -jar ${SWCG_JAR}/swagger-codegen.jar generate --enable-post-process-file --input-spec $1 --generator-name cpp-qt5-qhttpengine-server --template-dir MustacheFiles/ForQHTTPEngine --output $2

For generating the client:
java -jar ${SWCG_JAR}/swagger-codegen.jar generate --enable-post-process-file --input-spec $1 --generator-name cpp-qt5 --template-dir MustacheFiles/ForQtClient --output $2

Steps to reproduce
  1. Create the .yaml file from above.

  2. Generate the code per the two different command line spec above.

  3. Compare the generate code. For example:
    From the server-side file 'OAIContent.h':
    <---- cut ----->
    QByteArray getType() const;
    void setType(const QByteArray &type);

         virtual bool isSet() const override;
         virtual bool isValid() const override;
    
     private:
         QByteArray type;
    

<----- cut ---->

And from the client-side file 'OAIContent.h':
<----- cut ---->
QByteArray* getType() const;
void setType(const QByteArray* &type);

        virtual bool isSet() const override;
        virtual bool isValid() const override;

    private:
        QByteArray* type;

<----- cut ---->

Related issues/PRs

I think this issue: #407 may be closely related.

Suggest a fix

I think this has to do with the instantiation of the {{datatype}} value in the mustache code.

@auto-labeler
Copy link

auto-labeler bot commented Dec 18, 2018

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

Please review the labels and make any necessary changes.

@dtucker61
Copy link
Author

Addendum: I see the same behavior when I use 'type: string' without the 'format: byte' modifier. In this case, the server-side generates code that looks like:
QString getProperties() const;
void setProperties (const QString &properties) ;

while the client side generates:
QString getProperties() const
void setProperties(const QString
&properties) ;

Seems to be a problem with API types that map to Qt objects....

@dtucker61 dtucker61 reopened this Dec 19, 2018
@dtucker61
Copy link
Author

Sorry, did not mean to close the issue.

@etherealjoy
Copy link
Contributor

etherealjoy commented Jan 6, 2019

@dtucker61
latest master/4.0.0 is now the same behavior for both server and client
Fixed with #1284.

Could you please try it and provide feedback.
Thanks a lot.

@etherealjoy etherealjoy added this to the 4.0.0 milestone Jan 6, 2019
@dtucker61
Copy link
Author

Downloaded the 4.0.0 beta generator .jar file && replaced the 3.3.4 .jar file in our build environment.
The new .jar works to generate code that compiles and links using both the cpp-qt5-client and cpp-qt5-qhttpengine-server. Initial assessment -- this appears to work. Thanks much for your assistance.

Will continue testing on this side.

PS -- Found a typo in one of the cpp-qt5-qhttpengine-server .mustache files. Specifically, the file 'apirequest.cpp.mustache', line 80 -- there is an extra '(' after the '::fromStringValue' (i.e. line should be ... ::fromStringValue(QString ... ). You want me to create a separate issue?

@etherealjoy
Copy link
Contributor

Ahh OK, please close this and create a different one.
Many thanks for the feedback..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants