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

Feat/plugins schemas to new db #3778

Merged
merged 8 commits into from
Oct 4, 2018
Merged

Conversation

kikito
Copy link
Member

@kikito kikito commented Sep 16, 2018

No description provided.

@kikito kikito force-pushed the feat/plugins-schemas-to-new-db branch 10 times, most recently from 64bb88b to 6675897 Compare September 20, 2018 23:27
@kikito kikito force-pushed the feat/plugins-schemas-to-new-db branch 6 times, most recently from aedbf57 to aa8742b Compare September 21, 2018 14:03
@kikito kikito changed the title WIP - Feat/plugins schemas to new db Feat/plugins schemas to new db Sep 21, 2018
@kikito kikito force-pushed the feat/plugins-schemas-to-new-db branch 2 times, most recently from 13954de to 6db701c Compare September 21, 2018 14:57
@hishamhm
Copy link
Contributor

hishamhm commented Oct 2, 2018

Reviewing commit by commit!

Leaving a note here since there is no "general comment on commit": please rename fix(schema) default values for structs to fix(schema) default values for records to avoid confusion.

@@ -270,6 +270,9 @@ Schema.validators = {
end,

uuid = function(value)
if value == "" then
return true
end
Copy link
Contributor

Choose a reason for hiding this comment

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

This does look odd, and the commit says "Check if this is needed"... which plugin test needs this to pass?

Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like this is related to config.anonymous. I see you added is_present in the plugins to support both "" and ngx.null, I guess to avoid a migration (always a good goal!).

I wonder if we could get rid of these empty strings via process_auto_fields instead. Perhaps with a legacy annotation?

-- in process_auto_fields (for field.auto == false case only)
if field.legacy and field.uuid and output[key] == "" then
  output[key] == ngx.null
end

This would always clean up the data once it comes from the DB (it's a bit of a "migration transformation"). The plugins wouldn't need the is_present tests and this change to the uuid validator wouldn't be necessary (ie, we'd avoid messing up all UUID fields because of anonymous). What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

I like that! It didn't occur to me to do it that way.

kong/db/schema/init.lua Show resolved Hide resolved
kong/db/schema/init.lua Show resolved Hide resolved
output[key] = utils.random_string()
end
end

if context == "update" then
output[key] = adjust_field_for_update(field, output[key], nulls)

Copy link
Contributor

Choose a reason for hiding this comment

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

minor: the style guide says this is not necessary for one-liner if/then/else blocks

Copy link
Member Author

Choose a reason for hiding this comment

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

ok removed that one

kong/db/schema/init.lua Show resolved Hide resolved
fields = {
{ whitelist = {
type = "array",
elements = { type = "string", is_regex = true, match = ".*" },
Copy link
Contributor

Choose a reason for hiding this comment

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

I understand this match rule was already present in the old schema, but it does nothing useful ("match zero or more of any character"), right?

kong/plugins/datadog/schema.lua Show resolved Hide resolved
kong/plugins/request-termination/schema.lua Show resolved Hide resolved
@hishamhm
Copy link
Contributor

hishamhm commented Oct 2, 2018

The "pr" build of Travis seems to be failing over and over in the C*2 integration job with a weird error in the datadog test suite. Currently the are conflicts with next, and @bungle has fixed a flakiness problem in the datadog tests. Perhaps this will be fixed after this PR merges cleanly again?

@kikito kikito force-pushed the feat/plugins-schemas-to-new-db branch 3 times, most recently from d0f00b4 to a6880cd Compare October 3, 2018 17:22
@kikito kikito force-pushed the feat/plugins-schemas-to-new-db branch from a6880cd to 4cb6341 Compare October 3, 2018 17:25
@hishamhm hishamhm force-pushed the feat/plugins-schemas-to-new-db branch from 4cb6341 to 131a8f1 Compare October 3, 2018 17:58
@kikito kikito force-pushed the feat/plugins-schemas-to-new-db branch from 131a8f1 to 23169b5 Compare October 3, 2018 19:24
@hishamhm hishamhm force-pushed the feat/plugins-schemas-to-new-db branch from 23169b5 to 9f7bc77 Compare October 3, 2018 19:26
@kikito kikito force-pushed the feat/plugins-schemas-to-new-db branch from 9f7bc77 to df89f46 Compare October 4, 2018 11:59
@hishamhm hishamhm force-pushed the feat/plugins-schemas-to-new-db branch from 4fac07c to eb91de2 Compare October 4, 2018 17:44
@hishamhm hishamhm added pr/ready (but hold merge) No more concerns, but do not merge yet (probably a conflict of interest with another PR or release) and removed pr/please review labels Oct 4, 2018
Copy link
Contributor

@hishamhm hishamhm left a comment

Choose a reason for hiding this comment

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

All set, but waiting for master to be merged into next so we can remove the tests(helpers) workaround on this

hishamhm and others added 8 commits October 4, 2018 15:52
Entities already had non-nullable records by default
since 30789e7. However, plugin subschemas did not go through
the same preprocessing. This adds a new function
`Entity.new_subschema` that performs that same preprocessing.
We cannot use `between' because sometimes the condition is non-inclusive (`gt = 0`
does not include 0)
This calls `handle_missing_value` when propagating defaults
for records so that non-nullable records (as in Entities)
get their sub-tables created. Also refactors both
adjustment functions into one (the original version of
this patch missed the other function, so this avoids
it happening again).

Co-authored-by: Enrique García Cota <[email protected]>
UUIDs created with the old schema stored an empty string to
mean "value not present". We now use an explicit `null` for that.
This `legacy` annotation allows the schema library to transform
existing rows stored in the old format to use the new format
transparently.

Co-authored-by: Hisham Muhammad <[email protected]>
@hishamhm hishamhm force-pushed the feat/plugins-schemas-to-new-db branch from eb91de2 to 9e0d1c4 Compare October 4, 2018 19:02
@hishamhm hishamhm merged commit 9cda865 into next Oct 4, 2018
@hishamhm hishamhm deleted the feat/plugins-schemas-to-new-db branch October 4, 2018 19:35
@hishamhm
Copy link
Contributor

hishamhm commented Oct 4, 2018

Merged with a merge commit, as we do for major changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr/ready (but hold merge) No more concerns, but do not merge yet (probably a conflict of interest with another PR or release)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants