Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
feat(schema) add support for subschemas #3630
This resolves three difficulties that would appear when porting the Plugins entity over to the new DAO: loading the plugin configuration schema dynamically, the fact that this schema depends on a value of the entity row itself, and the fact that the specific plugin type can impose further constraints on values.
The old DAO implemented this by allowing records to have a
The new DAO implements this by allowing an entity (such as Plugins) to declare that it is extensible via subschemas:
kikito left a comment
I am not sure the parent needs to know where his subschemas are: the "kong.plugins.?.schema" part is not needed as far as I know - as long as we "keep track of the list of subschemas" when a new subschema is found.
Similarly, I don't think the abstract field abstraction is needed. It seems to me that the only reason to have them is to raise an error if someone wants to instantiate a Plugin without the correct subschema. But in that case we can still raise an error by detecting that the subschema_key doesn't correspond with any of the loaded subschemas.
We need that otherwise the knowledge of this path ends up hardcoded somewhere. This is already a problem with core entities because foreign relationships assume that other entities are core entities: https://github.com/Kong/kong/blob/master/kong/db/schema/init.lua#L1182-L1183 (@james-callahan has had problems with that line already). I don't want to repeat this. For foreign-key relationships we could have made it such that the
Unless you are proposing that we load every plugin beforehand, including their config schemas and eventual custom DAOs, and store them all in the same flat/single namespace. I think keeping these namespaces separate (at the schema level at least) is less prone to conflict.
For example, one possible (far off) future application of subschemas would be in a redesign of the Upstream entity into a more general Balancer entity where instead of a bunch of fields for hashing method, where we need to add fields each time we add a new method (e.g.
The reason it is there is so that the parent schema alone can used to produce the DDL stuff for creating the database table in the strategy, without knowledge of the concrete ones, and for forcing certain fields to be specialized (
@kikito I pushed a fixup commit (to be squashed when merged), based on the feedback you gave me today. It removes the
I think it reaches a nice middle-ground between the various approaches we suggested. Let me know what you think!