Skip to content

Releases: pb33f/libopenapi

v0.13.6

05 Nov 14:24
Compare
Choose a tag to compare

Same as 0.13, but with bugfixes reported by vacuum users. No new features

v0.13.3

04 Nov 20:27
Compare
Choose a tag to compare

Same features as 0.13, just more bugfixes

v0.13.2

04 Nov 16:38
Compare
Choose a tag to compare

Same as 0.13.1, just with a small bugfix to resolving error handling, something required by vacuum.

v0.13.1

04 Nov 16:04
Compare
Choose a tag to compare

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.

@sebkunz

v0.12.1

08 Oct 16:31
Compare
Choose a tag to compare

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.

#176
#174
#182

@nickajacks1

v0.12.0

05 Oct 13:43
Compare
Choose a tag to compare

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.

@TristanSpeakEasy
@Baliedge

v0.11.0

21 Sep 10:04
Compare
Choose a tag to compare

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

18 Sep 21:53
Compare
Choose a tag to compare

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

18 Sep 12:29
Compare
Choose a tag to compare

Fixed issue with comparing schemas. An edge case appeared where a property swap was causing bad logic to run. This has been resolved

Fixes #170

v0.10.4

16 Sep 15:41
Compare
Choose a tag to compare

Fixes the index handling properties named enum correctly, as identified in daveshanley/vacuum#339

No features in this release.