You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While examples are free to use anything, I think its helpful for us to have consistent patterns we follow. The sdk-config.yaml and sdk-migration-config.yaml target users, and so their default values do actually matter and should align with defaults. The kitchen-sink.yaml is contrived and can use any values, but its still probably helpful to use the defaults. One problem with the defaults is that they're not always defined. For example, the default value for .attribute_limits.attribute_value_length_limit is undefined. However, we do want to demonstrate setting some value for this in the example to verify we have the correct type in the schema. Maybe we can adopt a strategy of using the default when available, and when unavailable, using some dummy value with a callout that its not the default.
While examples are free to use anything, I think its helpful for us to have consistent patterns we follow. The
sdk-config.yaml
andsdk-migration-config.yaml
target users, and so their default values do actually matter and should align with defaults. Thekitchen-sink.yaml
is contrived and can use any values, but its still probably helpful to use the defaults. One problem with the defaults is that they're not always defined. For example, the default value for.attribute_limits.attribute_value_length_limit
is undefined. However, we do want to demonstrate setting some value for this in the example to verify we have the correct type in the schema. Maybe we can adopt a strategy of using the default when available, and when unavailable, using some dummy value with a callout that its not the default.Originally posted by @jack-berg in #108 (comment)
The text was updated successfully, but these errors were encountered: