-
Notifications
You must be signed in to change notification settings - Fork 8
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
Wildcard keys can override specific keys #16
Comments
This is a hacky fix for #16, preventing wildcard keys from overriding specific keys.
I have a hacky minimal fix on this branch. There's a test failing, and I'm curious if you (@w01fe) have any ideas for a less-hacky way to do this. I also need to add a failing test. |
I think the failing test is because it's also applying the logic to sequential schemas; I'm not sure how to distinguish them. |
Oh man, I haven't thought about this in so long. I just went back and looked a bit. I think the thing you have probably isn't right when there are optional keys as you notice. And it probably also does the wrong thing for sequences. I suspect I left the TODO because it seemed hard to do this right, and such schemas where this would do the wrong thing mostly seemed dubious (although the I suspect doing this properly would require beefing up the schema spec representation to provide a set of the "exceptions" for the remaining schema (if any). Perhaps that could just go directly into the existing Alternatively, there might be a way to work around this special case for maps inside the generators library. I have a 3-week old daughter so have my hands full at the moment but will do my best to answer questions or take another look sometime soon if it would be helpful. Thanks, Jason |
This is a hacky fix for #16, preventing wildcard keys from overriding specific keys.
@w01fe looks like I can fix this in schema, by tweaking the wildcard key schema with a constraint that it not equal any of the other keys:
would that be a bad way to do it? |
(I don't mind also adding a predicate to the collection spec that applies to any wildcard element, and just only using it from the map spec, but thought this was worth asking about since it's relatively simple) |
Your change seems fine to me as long as the tests all pass. I think this was always a bit of a gray area so hopefully nobody is relying on the old behavior, and this definitely seems more right. Thanks! |
This will fix [issue #16 in schema-generators] (plumatic/schema-generators#16), by wrapping any extra-keys schema in maps in a s/conditional that asserts that none of the extra keys can be equal to any explicit key in the map. This arguably reflects the real meaning of the extra-key entries, and in any case solves the schema-generators problem (when generated extra keys collide with explicit keys) and doesn't seem to cause any problems.
This causes the test in the previous commit to pass.
Looks like
{:a s/Int, s/Keyword s/Bool}
can fail when the key:a
gets coincidentally generated by thes/Keyword
key schema.This causes a spurious test failure for me every few weeks.
I see there's currently a comment to this effect:
Reproduction:
The text was updated successfully, but these errors were encountered: