joelittlejohn / jsonschema2pojo

Generate Java types from JSON or JSON Schema and annotate those types for data-binding with Jackson, Gson, etc
http://www.jsonschema2pojo.org
Apache License 2.0
6.24k stars 1.66k forks source link

Generate generic accessor for patternProperties #1638

Open UnasZole opened 1 month ago

UnasZole commented 1 month ago

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 commented 1 month ago

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).