Have you considered adding the @Singular and @EqualsAndHashCode ?

[MinyShrimp]

Have you considered adding the @Singular and @EqualsAndHashCode annotations to the Property and WeaviateClass (and other objects that perform similar roles)?

You could use the following code as an example:

package io.weaviate.client.v1.schema.model;

@Getter
@Builder
@ToString
@EqualsAndHashCode // <--- like this
@FieldDefaults(makeFinal = true, level = AccessLevel.PRIVATE)
public class Property {
    @Singular // <--- like this
    List<String> dataType;
}

@Getter
@Builder
@ToString
@EqualsAndHashCode // <--- like this
@FieldDefaults(makeFinal = true, level = AccessLevel.PRIVATE)
public class WeaviateClass {
    @Singular // <--- like this
    List<Property> properties;
}

By using the @Singular annotation, you can use the following code:

class Test {
    void test() {
        Property.builder()
                .dataType("string")
                .dataType("number")
                .build();

        WeaviateClass
                .builder()
                .property(Property.builder().dataType("string").build())
                .property(Property.builder().dataType("number").build())
                .build();

        // and Can use this
        WeaviateClass
                .builder()
                .properties(List.of(
                        Property.builder().dataType("string").build(),
                        Property.builder().dataType("number").build()
                ))
                .build();
    }
}

[aliszka]

Thank you @MinyShrimp for reporting the issue.

Indeed @EqualsAndHashCode annotation is missing in multiple data classes. We will add it soon.

As for @Singular annotation: it definitely is a nice feature and makes interface simpler and easier to use, though in our case it would be considered as breaking change. Builder will use the same method name for providing collection to its instance (properties in your example), but its behaviour will change. Instead of setting/replacing builder's collection with provided one, with @Singular in place it will copy elements from provided collection to builder's one. If builder is reused to create multiple instances of data classes, collections fields may contain much more elements than user intended to put. clearXYZ (clearProperties in your example) method would have to be called before setter to prevent mentioned scenario to happen.

We may add @Singular support in the future along with other breaking change features and create proper migration guide.