Releases: pb33f/libopenapi
v0.13.6
Same as 0.13, but with bugfixes reported by vacuum users. No new features
v0.13.3
Same features as 0.13, just more bugfixes
v0.13.2
Same as 0.13.1, just with a small bugfix to resolving error handling, something required by vacuum.
v0.13.1
Introducing the Rolodex!
The rolodex is the solution libopenapi has needed for some time. It reorganizes how the index works, how references are composed and how things are looked up when building the model.
The rolodex creates virtual filesystems for exploded specifications that are scattered across multiple local or remote locations. The rolodex can contain multiple local or remote filesystems for documents, and can lookup anything
via its fully qualified location.
Custom filesystems can be loaded in, instead of the local and remote ones provided by libopenapi as the rolodex uses fs.FS as an interface, so any custom implementation can be used.
This is a large breaking change for how the index operates, there are breaking changes to all low-level models, mainly with the introduction of a context.Context parameter. This is used by the rolodex to know where to resolve references from, when deeply nested recursive reference resolution.
The index no-longer operates the way it used to and how indexes are used by the rolodex is also new.
There should be minimal configuration changes at the top-level API for documents, and no changes to the high-level model.
New docs will be coming to pb33f.io soon to explain how it all works, but for the most part, users won't see it or know about it.
v0.12.1
Small changes in this release that update correct handling of exclusiveMinimum
and exclusiveMaximum
and rendering of minimum
and maximum
.
Also a few tunes small cleanups and chores, no new features.
v0.12.0
This release contains new generalized async processing logic, and some other fixes to additionalProperties
in the v3 Schema
.
The generalized async code written by @Baliedge replaces the specific/custom async processing code originally implemented per struct in the models. The async code is to allow for maximum speed when building models and one of my principals for this project.
This async code is required to provide a fix for the following downstream PRs and issues.
The next update in this release is a fix in the Schema
to correctly handle additionalProperties
. Originally it had an any
type, because folks do crazy things with this property.
However, it's been cemented as a DynamicProperty
and can now either be a Schema
, or a bool.
v0.11.0
Circular references mean different things to different consumers. They may or may not be valid use cases. So after much discussion, I've decided to allow engineers to override my opinions on circular references.
Polymorphic based references, or array based references may or may not be valid circles, an empty array can break the loop for example. This isn't clear in the spec as there can be no way of knowing. The default position of libopenapi
is to not ignore polymorphic (anyOf
, oneOf
, allOf
) loops, or array based loops.
Now this can be configured, Choose to ignore polymorphic loops, or array loops, or both.
To configure the resolver directly, there are two new methods available:
IgnorePolymorphicCircularReferences()
and IgnoreArrayCircularReferences()
The same properties exist on the datamodel.DocumentConfiguration
struct that allows them to be ignored when building a document. For example:
var d = `openapi: 3.1.0
components:
schemas:
ProductCategory:
type: "object"
properties:
name:
type: "string"
children:
type: "object"
anyOf:
- $ref: "#/components/schemas/ProductCategory"
description: "Array of sub-categories in the same format."
required:
- "name"
- "children"`
config := datamodel.NewClosedDocumentConfiguration()
// ignore polymorphic circular references.
config.IgnorePolymorphicCircularReferences = true
doc, err := NewDocumentWithConfiguration([]byte(d), config)
if err != nil {
panic(err)
}
m, errs := doc.BuildV3Model()
assert.Len(t, errs, 0)
assert.Len(t, m.Index.GetCircularReferences(), 0)
The second update in this release is that the datamodel.CircularReferenceResult
contains more detail on
what type of circular reference was located. This is valuable to determine if you should programmatically ignore the loop.
type CircularReferenceResult struct {
Journey []*Reference
Start *Reference
LoopIndex int
LoopPoint *Reference
IsArrayResult bool // if this result comes from an array loop.
PolymorphicType string // which type of polymorphic loop is this? (oneOf, anyOf, allOf)
IsPolymorphicResult bool // if this result comes from a polymorphic loop.
IsInfiniteLoop bool // if all the definitions in the reference loop are marked as required, this is an infinite circular reference, thus is not allowed.
}
The IsArrayResult
will be true if the loop has come through an array
The PolymorphicTypeResult
will be oneOf
, anyOf
or allOf
depending on which type was used and the
isPolymorphicResult
value will also be true, as before.
The docs have been updated for some more detail if required:
https://pb33f.io/libopenapi/circular-references/#circular-reference-results
v0.10.6
Rendering causes bits to be set on structs in the model. Concurrency causes race issues with reading a writing of these bits, as there is no locking in the model.
Until now. locking prevents concurrent renders that use a shared model from conflicting with one another.
Addresses #163 and pb33f/libopenapi-validator#23
v0.10.5
v0.10.4
Fixes the index handling properties named enum
correctly, as identified in daveshanley/vacuum#339
No features in this release.