Editor: Data types misses type: object
See original GitHub issueWhen I create a new data type (schemas under components), It doesn’t add type:object
to schema definition
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (6 by maintainers)
Top Results From Across the Web
Cache Miss – What It Is and How to Reduce It - Hostinger
Cache miss suggests that requested data is not available in cache memory. Read on to learn how to reduce them and make the...
Read more >You're Not My (Data) Type: An Intro to TypeScript — Part 2
A TypeScript object that is pre-defined and type inferred. Tuples and Union Types. The first type we'll look at is a tuple. A...
Read more >SQL Data Types | DigitalOcean
You miss the type INTERVAL of which there are 2 basic ones: INTERVAL SECONDS (can include fractions) and INTERVAL MONTHS. Type TEXT and...
Read more >Reading and writing data to the cache - Apollo GraphQL Docs
You can read and write cache data using GraphQL fragments on any normalized cache object. This provides more "random access" to your cached...
Read more >Implementing SQL data types
If I had to define it, I'd say that data type determines the kind, size, and range of data that can be stored...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
At the moment, apicurio doesn’t support inline object definitions. So you would need to create a global data type and then refer to it in the
application/json
media type in your screenshot. I’d like to support editing anobject
type inline within the response, but it’s not yet done.@EricWittmann
we already have documentation wrote in OpenAPI manually or by other tools that we would like to reuse. inline object definition is common feature, at least I feel like this and it’s needed for other tools compatibility.
second problem is that following your advice we fastly have a lot of object definitions that are in real only one-time used definitions. it’s make definitions list too long and distracts attention from really useful, commonly used structures in our apis. e.g. instead of have only
User
andShopItem
common defs, we ending with many less important types:ResponseXType
, ResponseYType,
ResponseZType` etc.