Data types in generated schema should be more specific

[augustawind]

I've noticed a couple of small, but important issues with how data types are handled in Swagger schema generation:

1. The format field, which can add helpful context to string types, isn't being used at all (except in this special case). This could be used to distinguish, for example, a plaintext string field (such as a description or name field) from a UUID field (which would be signified by "format": "uuid").
2. When dealing with Array types (from M2M or FK fields, for example), the item type is always set to "string" (see here). There are many scenarios where this doesn't make sense, e.g. when you have a ForeignKey field pointing to a model that uses an IntegerField as its primary key.

Is this something that's on your radar? I'd very much like to see these changes happen (and I'm willing to do the work!).

[tomchristie]

It's broadly on the horizon yup. I don't think it's something anyone else would be able to progress right now, as I'm the blocker on figuring out what approach we want to take here, but as the API docs for REST framework & the javascript client for Core API both come together I think we'll end up needing to look at types & controls more thoroughly than we have done to date.

[jisaacstone]

FYI I needed some similar functionality, which I achieved by subclassing coreapi.Field to add some of the OpenAPI 2.0 parameter fields (specifically default, collectionFormat, items) and modifying the encoder to read them.

If someone else needs this stuff feel free to reference my implementation

@tomchristie If you happen to like this approach I'd be glad to get more of the spec implemented & then submit a PR

[tomchristie]

@jisaacstone Cheers! The schema work is shaping up so I'll be in a position to share how we're going to tackle this soon enough (Nudge https://github.com/core-api/python-coreschema)

[paultiplady]

@tomchristie any update on the core schema that's underpinning this? I've hit this with nested objects in the schema (object is rendered as type string too, preventing us from rendering nested serializers). Do you have the design in place enough that some pieces could be farmed out to contributors, or are you still the bottleneck here?

Cheers

[zbyte64]

coreschema's String implementation supports a format parameter. I've used that to add date and date-time formats to DRF but the data was getting lost when openapi_codec decoded. I've forked and added format decoding, but encoding should be added as well: https://github.com/zbyte64/python-openapi-codec/commit/c376ffbb955ee33e9ba183d8d1961ce198c41d9e