Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensible MetaSchema #454

Merged
merged 4 commits into from
Dec 7, 2022
Merged

Extensible MetaSchema #454

merged 4 commits into from
Dec 7, 2022

Conversation

vigoo
Copy link
Contributor

@vigoo vigoo commented Dec 5, 2022

Makes MetaSchema extensible with known types, which are represented by their TypeId. Support for DynamicValue in MetaSchema is reimplemented in top of this functionality.

Projects having some huge important built-in types and using MetaSchema to serialize custom types can use this feature to significantly reduce the size required by the serialized schemas. A good example is zio-flow where the ZFlow and Remote types (as well as DynamicValue) are very common in serialized schemas.

Resolves #294

@vigoo vigoo requested a review from a team as a code owner December 5, 2022 10:07
import CaseSet._

type Labelled[BuiltIn <: TypeList] = (String, ExtensibleMetaSchema[BuiltIn])
type Lineage = Chunk[(Int, NodePath)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these two are exposed to the outside world, may be better to make them case class.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. They were type aliases in the existing MetaSchema and I did not want to change more than necessary. Should I do it in this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed

"value" -> MetaSchema
.Value(StandardType.IntType, NodePath.root / "type2" / "value2" / "value")
"value" -> ExtensibleMetaSchema
.Value[DynamicValue :: End](StandardType.IntType, NodePath.root / "type2" / "value2" / "value")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be helpful to have method-based constructors that can fill in DynamicValue :: End since it's so common. e.g. def value(...): MetaSchema[...].

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, in the companion object of ExtensibleMetaSchema, of course.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost did it :) but then I thought normal usage of MetaSchema does not really require dealing with its constructors, it is just this test suite. Normally you just use it as a serializable representation of a schema and not really manipulating it.

val refEq1 = meta1.toSchema eq Schema[Pet]
val refEq2 = meta2.toSchema eq Schema[DynamicValue]
assertTrue(refEq1, refEq2)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no tests for the type list functionality. Could be useful to add them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two test cases with ExtendedMetaSchema are trying to test that - they use type ExtendedMetaSchema = ExtensibleMetaSchema[DynamicValue :: Pet :: End] instead of the default. What else would you test?

@vigoo vigoo merged commit 1190d93 into zio:main Dec 7, 2022
@vigoo vigoo deleted the extensible-meta-schema branch December 7, 2022 12:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ability to extend SchemaAst with known types
2 participants