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

Schema subclasses contain duplicate fields #3094

Closed
padamstx opened this issue Jan 28, 2019 · 2 comments
Closed

Schema subclasses contain duplicate fields #3094

padamstx opened this issue Jan 28, 2019 · 2 comments

Comments

@padamstx
Copy link
Contributor

padamstx commented Jan 28, 2019

The way in which the various Schema subclasses (e.g. ArraySchema, StringSchema, etc.) are defined means that they are duplicating certain fields. For example, StringSchema is defined like this:

public class StringSchema extends Schema<String> {
    private String type = "string";
...
}

This causes StringSchema to have a DIFFERENT type field than is found in Schema.

To alleviate this, I'm proposing a slight change to Schema like this to introduce a ctor:

public class Schema<T> {
    ...
    public Schema(String type, String format) {
        this.type = type;
        this.format = format;
    }
    ...
}

and then StringSchema could be changed like this to use this new ctor:

public class StringSchema extends Schema<String> {

    public StringSchema() {
        super("string", null);
    }
    ...
}

Then BinarySchema could be changed like this:

public class BinarySchema extends Schema<byte[]> {

    public BinarySchema() {
        super("string", "binary");
    }
    ...
}

And ByteArraySchema could be changed like this:

public class ByteArraySchema extends Schema<byte[]> {

    public ByteArraySchema() {
        super("string", "byte");
    }
    ...
}

and most of the other Schema subclasses could be changed in a similar way.

Before I submit a PR for these changes, I just wanted to introduce the issue and see if there is general agreement on the solution. I don't think this will make any functional difference in the classes but would make things a little easier when debugging and would just make good "java sense" I think.
Comments?
cc: @wing328

@frantuma
Copy link
Member

frantuma commented Feb 1, 2019

Thanks for reporting and addressing this! it's indeed an issue which should be addressed, possibly similarly to your suggestion but slightly different, to maintain existing compatibility specifically for fluent interface.

This would basically mean:

  • remove private modifier in Schema type and format members
  • remove type and format members in all subclasses along with getter and setter, keeping fluent setter
  • add a public no arg ctor in all subclasses like:
    public IntegerSchema() {
        type = "integer";
        format = "int32";
    }
  • adjust equals, hashcode, and print, removing type and format

@padamstx
Copy link
Contributor Author

padamstx commented Feb 1, 2019

@frantuma Thanks for replying... I have some local changes that are basically what you've suggested above. I'll submit a PR soon for this.

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

2 participants