-
Notifications
You must be signed in to change notification settings - Fork 162
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
Conversation
import CaseSet._ | ||
|
||
type Labelled[BuiltIn <: TypeList] = (String, ExtensibleMetaSchema[BuiltIn]) | ||
type Lineage = Chunk[(Int, NodePath)] |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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") |
There was a problem hiding this comment.
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[...]
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
Makes
MetaSchema
extensible with known types, which are represented by theirTypeId
. Support forDynamicValue
inMetaSchema
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 iszio-flow
where theZFlow
andRemote
types (as well asDynamicValue
) are very common in serialized schemas.Resolves #294