Fix for #136, refactoring value_for_external_enum and separating out the enum variant and value extraction into a function usable in other contexts.

The context that requires this is impl Default for <Enum> , where we can make use of this function to extract the variant name for simple, and only simple, enums variants.

I notice that the generated code for schemas with defaults provides serde attributes such as default::default_i64<...>() Is it intended that the user of code-generation produce those default functions? It's easy enough to do. I was just wondering if you had a library in mind.

This adds Default to the base derive list, excluding enums where it requires a nightly feature. This allows the generated types to be used by other frameworks that expect models to have Default.

When we have a property with some field like so:

        "properties": {
          "iterations": {
            "format": "int64",
            "type": "string"
          },

Typify crashes with a panic

Caused by:
  process didn't exit successfully: `/Users/<redacted>/projects/<redacted>/crates/target/debug/build/<redacted>-631c4662e317d757/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'not yet implemented: Some(
      "int64",
  )', /Users/<redacted>/.cargo/git/checkouts/typify-288d5a84bbbe6a46/b712fe6/typify-impl/src/convert.rs:418:26
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

When a schema describes nested newtype structs where the inner value has some kind of constraint on it we generate code like:

#[derive(Clone, Debug, Deserialize, Serialize)]
pub struct Outer(Inner);
// ...
#[derive(Clone, Debug, Deserialize, Serialize)]
pub struct Inner(String);

impl std::convert::TryFrom<Inner> for Outer {
    type Error = &'static str;
    fn try_from(value: Inner) -> Result<Self, Self::Error> {
        if ![
            super::Inner("a".to_string()),
            super::Inner("b".to_string()),
            super::Inner("c".to_string()),
        ]
        .contains(&value)
        {
            Err("invalid value")
        } else {
            Ok(Self(value))
        }
    }
}

This will fail to compile as contains requires T: PartialEq<T>. (ignoring the super:: which is a separate issue)

The attached changes add a PartialEq derive to the Inner type specifically when we are generating this nested case. The other option here would be to inspect the Inner type at output time and add the derive there.

Also unsure if there are additional cases I didn't think of where a failing TryFrom will be generated.

If code was using with_derive("Foo"), and Foo is added to the base derive list, the result is a duplicate derive.

This prevents that from being a failure, and also sorts the combined derives.

It seems that the presence of the maxLength field in a string enum property causes the addition of extra super:: keywords in the codegen file. Below is the failing schema, the compile error, and a schema with the maxLength field removed that successfully builds.

failing schema:

{
  "$id": "https://example.com/arrays.schema.json",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "example title",
  "type": "object",
  "properties": {
    "enum_property": {
      "description": "name",
      "type": "string",
      "maxLength" : 32,
      "enum": ["first", "second"]
    }
  }
}

compile error:

error[E0433]: failed to resolve: there are too many leading `super` keywords
   |
26 |             super::ExampleTitleEnumPropertyInner("first".to_string()),
   |             ^^^^^ there are too many leading `super` keywords

error[E0433]: failed to resolve: there are too many leading `super` keywords
   |
27 |             super::ExampleTitleEnumPropertyInner("second".to_string()),
   |             ^^^^^ there are too many leading `super` keywords

Changes required to write schema

{
  "$id": "https://example.com/arrays.schema.json",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "example title",
  "type": "object",
  "properties": {
    "enum_property": {
      "description": "name",
      "type": "string",
-     "maxLength" : 32,
      "enum": ["first", "second"]
    }
  }
}

Supported by the serde() annotation in derive macros, which otherwise will assume that serde is a direct crate dependency. When a macro emits a type that derives Serialize/Deserialize, the user of that macro would normally have to directly depend on serde themselves for the resulting expansion of those derive macros. This can be cumbersome when consuming serde transitively via some other crate (i.e. progenitor).

https://github.com/serde-rs/serde/blob/5a8dcac2ed1407fab3f7fd23f2d56af42dcd448f/serde_derive/src/internals/attr.rs#L556-L561

Hey everyone, I encountered an openapi spec with a decimal format (primarily for currency type amounts) and figured this would be a reasonable addition to the library. This change adds support for rust_decimal to typify, inspired by the chrono support. Let me know if you have any objections/feedback to this and I'd be happy to address.

By the way, great work on progenitor and this library. I'm really liking the direction these are heading and hoping I can make use of these in the future.

This is the openapi spec in question: https://raw.githubusercontent.com/alpacahq/alpaca-docs/master/oas/broker/openapi.yaml

Currently, typify can generate code that depends on uuid and chrono. It might be useful to enable support for other packages or it might be useful to deny use, say, of uuid and represent a { "type": "string", "format": "uuid" } as a String rather than as an uuid::Uuid. One could even imagine allowing substitutes for the std types for arrays, maps, and sets.

In addition, it could be useful to allow consumers to specify new associations between formats and Rust types or to override existing ones. For example, a user might want to use rust_decimal::Decimal" for the "decimal" format orchrono::naive::NaiveDatefor the "date" format (rather thanchrono::Date`).

We could modify the macro, builder, and command-line interfaces to allow this (perhaps all through a shared Settings type). e.g.

import_types!(
    schema = "../example.json",
    allow_packages = [uuid, chrono],
    additional_string_formats = {
        "decimal" = "rust_decimal::Decimal",
        "date" = "chrono::naive::naiveDate",
    },
);

Bumps uuid from 0.8.2 to 1.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

JSON Schema can define types that have cycles. This is simple to handle in languages like JavaScript or Java, but more complex in Rust since those cycles must be explicitly broken with a Box<T>. Note that use of a Vec or HashMap also breaks the containment cycle but has implications for derive computation which we will discuss later. Note too that where one "breaks" a cycle may have multiple solutions, some that require more breaks than others. Note also that it may not be feasible to reconstruct the types e.g. if the JSON Schema were derived from Rust types because the information about Box indirections is explicitly discarded (and probably reasonably so, but one could imagine including hints; more on that later as well).

Currently we break trivial A -> A cycles such as:

struct A {
    a: Option<Box<A>>, // this needs to be boxed
}

We can do this without a bunch of graph traversal and it solved a proximate problem.

The more general case requires us to decompose the type graph into strongly connected subgraphs that form a DAG (e.g. with algorithms proposed by Tarjan, Dijkstra or Kosaraju). In this case, the edges are defined by structure or newtype containment either directly or via an Option type. Within each strongly connected subgraph we then would determine where to "break" the cycles by inserting Boxes. The general case of this requires exponential time to compute. While the number of nodes (types) in a cycle is likely to be small, we still may elect for a heuristic, the simplest of which would be to cut all edges. There's very little harm in cutting more than is absolutely required--the serialization isn't affected for example--the only consequence is to the legibility and ergonomics of the generated types.

For JSON Schema generated from rust types, it could be helpful to annotate boxed types with an extension. This could act as a heuristic when slicing a strongly connected component i.e. we use these extensions to see if they properly break the containment cycle and do something else if they don't.

The derive macros we apply to types have a similar problem. Consider, for example, the following type:

struct A {
    value: u32,
}

For this struct we could #[derive(Eq, PartialEq)], but if we change the u32 to an f32 we could not! A Vec<T> is Eq only if T: Eq and a HashSet<T> isn't Ord regardless of the traits implemented by T.

From the list of desirable traits to implement such as Hash, Ord, and Eq, the ones we can apply to a type depend on the types to which it refers. And those references may form a cycle. As above, we must compute the strongly connected components. Above the edges were containment; here the edges are all references (i.e. a Vec is an edge here but not above`). Within each strongly connected component we must take the intersection of all supportable traits.

JSON schema gives us two direct sources of types names: the keys in references dictionary and the title field in schema metadata. Note also that while the former are necessarily unique, the latter may not be. In addition, we can get hints about names. Consider for example a JSON object that looks like this:

{
    "fooObj": {
        "a": 7,
        "b": 8
    }
}

The outer object may have a name, but the value of fooObj may not (or it may have a title that is not unique). We could include a "distinguishing hint" in these cases which might be the enclosing type and property name, or may come from the external caller e.g. our OpenAPI processor could use the operationId.

After processing all types, we could choose to always include the distinguishing hint in the name, only include it if it was needed to resolve conflicting types, or raise an error if it as needed to disambiguate conflicting types.

This would require a change in the API which currently is of the form schemars::schema::Schema -> proc_macro2::TokenStream i.e. we will no longer be sure of the type name until all schemas have been examined.