If I set one schema for a ServicePlan (e.g. the Schema for instance creation parameters), the broker's catalog will also contain
the schema keys for the other cases (e.g. instance update and binding creation).
Their Schema's parameters field will then be null, which unfortunately confuses some platforms.
"schemas": {
"service_instance": {
"create": {
"parameters": {
"$schema": "http://json-schema.org/draft-07/schema",
"properties": {
"foo_prop": {
"type": "integer"
}
},
"title": "instance creation params",
"type": "object"
}
},
"update": {
"parameters": null
}
},
"service_binding": {
"create": {
"parameters": null
}
}
}
vs
"schemas": {
"service_instance": {
"create": {
"parameters": {
"$schema": "http://json-schema.org/draft-07/schema",
"properties": {
"foo_prop": {
"type": "integer"
}
},
"title": "instance creation params",
"type": "object"
}
}
}
}
This is because the fields of ServiceSchemas and ServiceInstanceSchema are structs, not pointers to structs.
Originally, they had the json:"omitempty" tag, so I guess the idea was that they should be optional, but that doesn't seem to work with structs in go.
I'm not sure what to do about this without causing a breaking change, though.
If I set one schema for a
ServicePlan(e.g. the Schema for instance creation parameters), the broker's catalog will also containthe schema keys for the other cases (e.g. instance update and binding creation).
Their
Schema'sparametersfield will then benull, which unfortunately confuses some platforms.vs
This is because the fields of
ServiceSchemasandServiceInstanceSchemaare structs, not pointers to structs.Originally, they had the
json:"omitempty"tag, so I guess the idea was that they should be optional, but that doesn't seem to work with structs in go.I'm not sure what to do about this without causing a breaking change, though.