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

Generate generic accessor for patternProperties #1638

Open
UnasZole opened this issue Oct 10, 2024 · 1 comment
Open

Generate generic accessor for patternProperties #1638

UnasZole opened this issue Oct 10, 2024 · 1 comment

Comments

@UnasZole
Copy link

Hi,

This issue is essentially a duplicate of #1067 , which you closed in 2020. It is not, however, a duplicate of #182 .

#182 is about full validation of pattern properties, which is, as you correctly state in the issue, practically impossible to express in POJOs.
This issue, however, is about just being able to access the properties, which should be possible.

Consider the following schema :

    {
      "type": "object",
      "properties": {
        "myDomain/myProperty": {
          "description": "This is an explicitly defined property, in the reserved myDomain prefix.",
          "type": "string"
        }
      },
      "patternProperties": {
        "^(?!myDomain/).*$": {
          "description": "Additional properties that must not contain the myDomain prefix.",
        }
      },
      "additionalProperties": false
    }

The effect of this construct is only to reserve a "namespace" (as a property prefix name) in an API, to ensure one is free to define new properties later, without risking that people are already using the same name for a different purpose.

For this schema, jsonschema2pojo sees "additionalProperties: false" so does not generate a generic getter - and completely ignores the patternProperties, making these fields unreachable.

My suggestion is to generate the getAdditionalProperties getter when patternProperties are present, even if additionalProperties is false.

@UnasZole
Copy link
Author

Looking further in the comments of #182, it seems that the question of being able to access the data with additionalProperties false was already discussed there, even if it was not the initial topic of the issue.
Feel free to close this ticket as duplicate again if you feel like it - nevertheless, it may make sense to have two distinct tickets for two different issues (accessing data vs validation).

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

No branches or pull requests

1 participant