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

Some properties with default values not inserted #179

Closed
IsmoKarkkainen opened this issue Mar 12, 2024 · 4 comments · Fixed by #180
Closed

Some properties with default values not inserted #179

IsmoKarkkainen opened this issue Mar 12, 2024 · 4 comments · Fixed by #180

Comments

@IsmoKarkkainen
Copy link

Using insert_property_defaults results in some properties with defaults not being inserted. The attached txt file
defaults_issue.txt
is a ruby script that demonstrates the issue. Save and rename to defaults_issue.rb and run. (Attaching rb file was not allowed, hence renamed.)

  1. When run as is, the check finds item4 is missing buggy.
  2. When you change the order of buggy and bbbb in the schema, item4 is missing bbbb.
  3. When you delete item5 from data, then item3 is missing cccc.
  4. Have bbbb in schema as the first property and have item5 removed, then item3 is missing bbbb.
  5. Have bbbb in schema as the first property and have item5 present, then item4 is missing bbbb.

There are probably other variations that produce something odd. I originally had meta_schema: 'https://spec.openapis.org/oas/3.1/dialect/base' but dropped that when simplifying the schema and data.

Ruby version 3.1.2, json_schemer 2.2.0.

davishmcclurg added a commit that referenced this issue Mar 12, 2024
The keys used to collect property defaults are mutable hashes, which
causes weird hash table problems when they're modified (`#hash` no
longer matches even though they have the same `#object_id`).
Explained here: https://docs.ruby-lang.org/en/3.3/Hash.html#class-Hash-label-Modifying+an+Active+Hash+Key

I think this problem got covered up a bit because it requires more than
8 keys for values to be dropped.

`compare_by_identity` fixes things by just using `#object_id` to compare
hash keys. It stays consistent after the hash key is mutated.

From the [docs][0]:

> Note: this requirement does not apply if the Hash uses
> `compare_by_identity` since comparison will then rely on the keys'
> object id instead of `hash` and `eql?`.

Fixes: #179

[0]: https://docs.ruby-lang.org/en/3.3/Hash.html#class-Hash-label-User-Defined+Hash+Keys
@davishmcclurg
Copy link
Owner

Hi @IsmoKarkkainen! Thanks for opening this—it's a strange one. I think I found the problem and the fix: #180
Do you mind trying it out?

@IsmoKarkkainen
Copy link
Author

Happy to try it out.

I changed the test script and the code that originally showed the problem with real schema and data to require_relative the json_schemer/lib/json_schemer in the new branch.

Test script still shows the issue but in the original code one case of missing property with default was fixed. Another one in there remains.

@davishmcclurg
Copy link
Owner

davishmcclurg commented Mar 13, 2024

require_relative the json_schemer/lib/json_schemer in the new branch.

You might be getting the wrong code since require_relative doesn't set the rest of the require statements in lib/json_schemer.rb to load correctly. I usually take the easy way out and use bundler/inline for stuff like this. In your script, you can replace:

require 'json'
require 'json_schemer'

With:

require 'bundler/inline'
gemfile do
  source 'https://rubygems.org'
  gem 'json'
  gem 'json_schemer', path: '/path/to/json_schemer/repo/with/branch/checked/out'
end

Pulling directly from github also works, but it's slower to run:

gem 'json_schemer', git: 'https://github.com/davishmcclurg/json_schemer', branch: 'compare-instance-locations-by-identity'

@IsmoKarkkainen
Copy link
Author

Ok, now the fields are present as the script does not complain and the real case has all omitted fields with defaults in place as well. Works. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants