Repository navigation
Data types in generated schema should be more specific #25
Description
Activity
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.
Reacted by Augusta Rohde, Lyle Scott III and Craig BlaszczykFYI I needed some similar functionality, which I achieved by subclassing
coreapi.Fieldto add some of the OpenAPI 2.0 parameter fields (specificallydefault,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
@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)
@tomchristie any update on the core schema that's underpinning this? I've hit this with nested objects in the schema (
objectis rendered as typestringtoo, 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
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: zbyte64@c376ffb
I've noticed a couple of small, but important issues with how data types are handled in Swagger schema generation:
formatfield, 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").itemtype 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!).