0.14.0 - schema_ref swaps precedence

schema_ref swaps precedence

This is another technically backwards-incompatible change, though it's very likely to be noticeable:

• schema_ref now lets the "local" schema take precedence over the schema being referenced. This way, if a shared schema that you are specifying with schema_ref defines a field foo, and your schema also defines a field foo, the version of the field from your local schema will take precedence.

As an example, here's a registry with my_common_schema

registry:
  my_common_schema:
    type: dict
    fields:
      foo: {type: string}

Now, if somewhere we have a snippet like so:

schema_ref: my_common_schema:
fields:
  foo: {type: integer}

Then a foo field will be validated as an integer instead of a string. In previous versions, the foo from my_common_schema would be used instead.

debug

There is now a debug directive that prints out the schema and value when the schema is being applied to a value. Specify a message to include in the debug output, so you know which debug output belongs to which schema.

type: dict
debug: "This is my dict!"

0.13.0 - BACKWARDS INCOMPATIBLE: defaults are now normalized, and `default_copy` and `metadata` are introduced

This new feature release has one important backwards incompatible change:

BACKWARDS INCOMPATIBLE: defaults are now normalized

Previously, a default value would not have any further schema applied to it. That means that the following schema would not fail when applied to {}:

type: dict
fields:
    foo:
      type: string
      default: 0

In 0.13.0, this will now raise a BadType error when applied to {}, because the default value, 0, does not match the type string.

More importantly, this allows for more easily normalizing to nested structures with defaults:

type: dict
fields:
  foo:
    type: dict
    default_setter: dict
    fields:
      bar: {type: integer, default: 0}

Previously, this schema applied to {} would result in {foo: {}}. Now, in 0.13.0, it will result in {foo: {bar: 0}}.

default_copy

The new default_copy directive allows specifying a value which will be (deeply) copied every time it is inserted into a document. This is an ergonomic improvement for when you want to specify a default value in YAML with mutable data structures, such as default_copy: {"foo": []}.

metadata

The new metadata directive is a no-op. It's meant to allow application authors to embed useful information into their Sureberus schemas to be used in an application-specific way.

0.12.0 - coerce_with_context and coerce_post_with_context

0.12.0 brings two new directives: coerce_with_context and coerce_post_with_context. These directives allow coercing with access to the context (most useful for accessing tags in the context).

0.11.2 - fix `choose_schema` selecting another schema that uses `choose_schema`

Similar to the bugfix for schema_ref in 0.10.3, this release fixes bugs in choose_schema and the various when_{key,tag}_{exists,is} directives when they are used to select schemas that, themselves, use the same directive to select more schemas.

0.11.1 - when_type_is error reporting

Improved when_type_is error reporting

0.11.0 - when_type_is

This is a new feature release that introduces the when_type_is sub-directive of the choose_schema directive. This new directive allows selecting a schema based on the type of the value.

0.10.3 - schema_ref to schemas that use schema_ref

This release fixes a bug that prevented use of schema_ref to merge in a schema that itself used schema_ref.

0.10.2 - schema_ref precedence

This release fixes a bug where schema_ref merged schemas in the wrong order -- now, the referred-to schema takes precedence over the outer schema.

0.10.1 - remove all deepcopy of schemas

Because deepcopy can sometimes fail if a type is unpicklable, we now avoid deepcopying schemas entirely. This was done in various places, such as schema_ref, when_tag_is, etc. This would only be a problem if you used closures (used as e.g. coerce directives) or default values that referred to complex unpicklable objects.

0.10.0 - schema_ref merges fields

Now, when schema_ref is used, fields defined in the referred-to schema get merged into the outer schema's fields.