Generate hashCode and equals

[miguel-vila]

Description

Generate hashCode and equals methods.

Issues Resolved

#312

[miguel-vila]

@Xtansia I have addressed most of your comments, the remaining one is regarding using an import instead of the fqn for java.util.Objects. Not sure how to do that.

I'm also interested in these changes because I want to have these methods in classes like TypeMapping and IndexSettings but I see that they are not being codegenerated at the moment. What should be done for that?

[Xtansia]

I'm also interested in these changes because I want to have these methods in classes like TypeMapping and IndexSettings but I see that they are not being codegenerated at the moment. What should be done for that?

@miguel-vila Yeah, we're currently doing a bit of a piecemeal approach to get things to be generated. It's somewhat slow going as when we do generate new sections there are breaking changes and other differences with the current client implementation, which requires evaluating between the client, the spec & the server what the correct expectation is.

So for some of the more complex structures it might be faster/easier to add them to your required types by hand. However if you're interested in helping out with moving even 1 or 2 requests to be generated that would be amazing.

[miguel-vila]

@Xtansia I would prefer not to add those manually, but not sure what would be the changes needed to include them in the codegeneration. Locally, I modified the OPERATION_MATCHER constant in the CodeGenerator class to include and(namespace("indices"), named("get")) and I'm seeing some errors :

java.lang.UnsupportedOperationException: Can not get type name for oneOf: [org.opensearch.client.codegen.openapi.OpenApiSchema@134060ce[pointer=/components/schemas/_common.analysis:TokenFilter/oneOf/0], org.opensearch.client.codegen.openapi.OpenApiSchema@33443e63[pointer=/components/schemas/_common.analysis:TokenFilter/oneOf/1]]
        at org.opensearch.client.codegen.model.SpecTransformer.mapOneOf(SpecTransformer.java:467
...

Is it possible that these errors would require more changes than adding the methods manually?

[Xtansia]

@Xtansia I would prefer not to add those manually, but not sure what would be the changes needed to include them in the codegeneration. Locally, I modified the OPERATION_MATCHER constant in the CodeGenerator class to include and(namespace("indices"), named("get")) and I'm seeing some errors :

java.lang.UnsupportedOperationException: Can not get type name for oneOf: [org.opensearch.client.codegen.openapi.OpenApiSchema@134060ce[pointer=/components/schemas/_common.analysis:TokenFilter/oneOf/0], org.opensearch.client.codegen.openapi.OpenApiSchema@33443e63[pointer=/components/schemas/_common.analysis:TokenFilter/oneOf/1]]
        at org.opensearch.client.codegen.model.SpecTransformer.mapOneOf(SpecTransformer.java:467
...

Is it possible that these errors would require more changes than adding the methods manually?

• For TokenFilter it'd require adding title: properties to the oneOf: in the spec to be able to generate the tagged union with the correct "Kind"s (https://github.com/opensearch-project/opensearch-java/blob/main/java-client/src/main/java/org/opensearch/client/opensearch/_types/analysis/TokenFilter.java).
• TokenFilterDefinition will be more complicated though as support for the discriminated tagged unions isn't in the codegen yet (https://github.com/opensearch-project/opensearch-java/blob/main/java-client/src/main/java/org/opensearch/client/opensearch/_types/analysis/TokenFilterDefinition.java).

There's likely more edge cases that'll pop up with something as expansive as indices.get, but would also unblock a lot of things with getting them implemented. I'll give it an investigate and see if I can get it working.