"using" in an entity without declaring an OpenAPI array

[davel]

Hello,

I am trying to use Raisin for an API which returns a single row of data, read by calling DBIx::Class's ->find(). I am having trouble making the generated OpenAPI / Swagger schema agree with the generated JSON.

I have two Raisin::Entity classes. One represents the row from DBIx::Class. The other represents the JSON data presented by an endpoint. It refers to the first via expose 'data', using => .... When the Swagger schema is generated, it declared the data is an array, when it is in fact an object represented by a hash.

Is there a way to make Raisin generate a schema matching the returned data?

Many thanks,
Dave

[khrt]

Hi,

that happens, because DBIx::Class's ->find() returns DBIx::Class::ResultSet as result.

If you could provide me with sample data and application maybe I might help then.

Thanks.

[davel]

The problem is that swagger.json does not agree with the generated output. For example in the music app, swagger.json claims that /artists returns data described by,

               "200" : {
                  "description" : "List",
                  "schema" : {
                     "$ref" : "#/definitions/MusicApp::Entity::Artist-302668EB84"
                  }
               },

However, MusicApp::Entity::Artist is not what is returned. Instead, we get a hash with elements count and data.

 `{"count":2,"data":[{"hash":"10","artist":"Nirvana", ...

You can fix this when an array is returned, eg.
davel@bb5fb43

.... but you cannot fix this where a single object is returned, such as with the /artists{id} endpoint. This change,
davel@c4f9eda

Causes data to be described as an array, which is incorrect.

Is there some way I can get the generated swagger to agree with the returned data for the /artists/{id} endpoint?

[khrt]

From what I understand now, it is not possible to reach the agreement between Swagger and the presenter.

As a solution to that we can introduce an argument to Entitie's expose to say the field is HASH or ARRAY.

What do you think?

[davel]

That would make sense to me. Also potentially useful for representing a has_one relationship from DBix::Class.