[BUG] No setter function generated for arrays

[julesdent]

Bug Report Checklist

• [ x] Have you provided a full/minimal spec to reproduce the issue?
• [ x] Have you validated the input using an OpenAPI validator (example)?
• [ x] What's the version of OpenAPI Generator used?
• [ x] Have you search for related issues/PRs?
• [ x] What's the actual output vs expected output?
• [Optional] Bounty to sponsor the fix (example)

Description

No setter function is generated for an array.

openapi-generator version

4.1.1

OpenAPI declaration file content or url

openapi: 3.0.0
servers:
  - description: SwaggerHub API Auto Mocking
    url: 'https://virtserver.swaggerhub.com/'
info:
  description: API
  version: 1.0.1
  title: API
  termsOfService: 'http://swagger.io/terms/'
tags:
  - name: FuelCosts
paths:
  '/FuelCosts':
    get:
      description: Obtain fuel costs
      tags:
        - FuelCosts
      summary: Get fuel cost
      operationId: GetFuelCostQuery
      responses:
        '200':
          description: Successful operation
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/FuelCost'
      security:
        - ApiKeyAuth: []
components:
  schemas:
    FuelCost:
      type: object
      properties:
        Remarks:
          type: array
          items:
            type: string

Command line used for generation

java -jar openapi-generator-cli-4.1.1.jar generate -i ./Bug.json -g cpp-pistache-server -o generated

Steps to reproduce

Generate the C++ code from the spec. In the generated FuelCost.h, there is a getter function for Remarks but no setter:
///

///
///

std::vectorstd::string& getRemarks();
bool remarksIsSet() const;
void unsetRemarks();

Related issues/PRs

#3271

Suggest a fix

As a workaround, you can derive a class from FuelCost and add a setter function manually, but this should really be handled by the generator.

[auto-labeler]

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

The team will review the labels and make any necessary changes.

[wing328]

there is a getter function for Remarks but no setter:

What does the correct code for setter look like? That can help us to update the mustache template more easily.

[julesdent]

I would expect the setter to look something like this:

void FuelCost::setRemarks(const std::vector<std::string>& value)
{
    m_Remarks = value;
    m_RemarksIsSet = true;
}

[julesdent]

A setter like the following would also be useful to allow setting from any container type:

    template <typename IteratorType>
    void setRemarks(IteratorType Begin, IteratorType End)
    {
        m_Remarks.assign(Begin, End);
        m_RemarksIsSet = true;
    }

[etherealjoy]

@julesdent
Actually there is no setter for the array because the array could be get and items inserted directly.

But this is a common request, so we will look into this as it is not a breaking change.

[etherealjoy]

@MartinDelille @muttleyxd @stkrwork @etherealjoy

[muttleyxd]

@etherealjoy I was working on this, but got sidetracked in the end (and my approach had too much code-breaking changes)
#3417

Should we tackle this just by adding the required setters?
Also .get() is broken since it doesn't set 'isSet' variable IIRC

[etherealjoy]

@etherealjoy I was working on this, but got sidetracked in the end (and my approach had too much code-breaking changes)
#3417

Yes I checked the other issue again today, and I agree generally about refactoring but code breaking is bad experience for end users, unless we have a major version going forward.
Then I leave this with you to continue.

Should we tackle this just by adding the required setters?

Yes, I think we could add, there are too many users expecting it.

Also .get() is broken since it doesn't set 'isSet' variable IIRC

Indeed, one way we can check is during serialization if there are items in the map, vector, (like how qt5 client is doing), either one is fine, (but if we expose get and set and user can set the array with a get )

[muttleyxd]

Yes I checked the other issue again today, and I agree generally about refactoring but code breaking is bad experience for end users, unless we have a major version going forward.
Then I leave this with you to continue.

I guess we could think about switching to my approach for 5.0 release? This would yield much smaller amount of code. Also we could use Pistache::Optional for optionals, so everything could be a structure and have optional fields implemented in simple way.

Yes, I think we could add, there are too many users expecting it.
Okay, let's do it for 4.*

Indeed, one way we can check is during serialization if there are items in the map, vector, (like how qt5 client is doing), either one is fine, (but if we expose get and set and user can set the array with a get )
To clarify, what should we do here:

• add 'set', which would set isSet
• make 'get' set isSet
• auto-detect if vector is set, problem is that someone may want to send and empty array

I'd go with make 'get' set isSet, if someone will want an empty array, they could call get(), if someone doesn't want it, they could use unset

[etherealjoy]

add 'set', which would set isSet
make 'get' set isSet
auto-detect if vector is set, problem is that someone may want to send and empty array
I'd go with make 'get' set isSet, if someone will want an empty array, they could call get(), if someone doesn't want it, they could use unset

Just a small proposal to your thought process here
What about set setting the isSet value.
If the array is empty and the isSet is set then we send anyway. Covers use case of user wanting to send empty array

If the array is not empty we send anyway, covers all exisiting cases. User could have accessed it with the get, or might have explicitly set with the set method.

[etherealjoy]

I guess we could think about switching to my approach for 5.0 release? This would yield much smaller amount of code. Also we could use Pistache::Optional for optionals, so everything could be a structure and have optional fields implemented in simple way.

Lets also ask @wing328 for his opinion on this.

[muttleyxd]

Just a small proposal to your thought process here
What about set setting the isSet value.
If the array is empty and the isSet is set then we send anyway. Covers use case of user wanting to send empty array

If the array is not empty we send anyway, covers all exisiting cases. User could have accessed it with the get, or might have explicitly set with the set method.

Take a look at #3837