You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@iceberg.apache.org by GitBox <gi...@apache.org> on 2021/03/17 19:16:21 UTC

[GitHub] [iceberg] Sealina opened a new issue #2347: Type Equality Check

Sealina opened a new issue #2347:
URL: https://github.com/apache/iceberg/issues/2347


   Hello,
   
   I'm using iceberg 0.10.0 and Junit 5 for unit testing my app based on iceberg. I noticed something out of expectation as the following
   
   ```
   ...
   @Test
   public MyUnitTest() {
       assertEquals(
           new org.apache.iceberg.types.Types.IntegerType(),
           new org.apache.iceberg.types.Types.IntegerType()
       )
   }
   ```
   Output:
   ```
   ...
   java.lang.AssertionError: expected: org.apache.iceberg.types.Types$IntegerType<int> but was: org.apache.iceberg.types.Types$IntegerType<int>
   Expected :org.apache.iceberg.types.Types$IntegerType<int>
   Actual   :org.apache.iceberg.types.Types$IntegerType<int>
   ...
   ```
   
   It looks like the iceberg types are using the default Java Object way of equality check (pointer equality instead of value equality). I want to know if this is by design, or if there's other ways of checking equality for iceberg types.
   
   Thank you


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


[GitHub] [iceberg] openinx commented on issue #2347: Type Equality Check

Posted by GitBox <gi...@apache.org>.
openinx commented on issue #2347:
URL: https://github.com/apache/iceberg/issues/2347#issuecomment-801706823


   For `IntegerType`,  we'd better to use the `typeId` to accomplish the assertion like:
   
   ```java
       assertEquals(IntegerType.typeId(),  IntegerType.typeId());
   ```


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


[GitHub] [iceberg] openinx closed issue #2347: Type Equality Check

Posted by GitBox <gi...@apache.org>.
openinx closed issue #2347:
URL: https://github.com/apache/iceberg/issues/2347


   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


[GitHub] [iceberg] Sealina commented on issue #2347: Type Equality Check

Posted by GitBox <gi...@apache.org>.
Sealina commented on issue #2347:
URL: https://github.com/apache/iceberg/issues/2347#issuecomment-804221597


   Thank you. On top of that, I also detected that this statement will fail:
   
   ```
   assertEquals(
       Types.NestedField.required(1, "FieldName", new Types.IntegerType()),
       Types.NestedField.required(1, "FieldName", new Types.IntegerType())
   )
   ```
   because NestedField equality relies on equality of type object (not typeId): https://github.com/apache/iceberg/blob/master/api/src/main/java/org/apache/iceberg/types/Types.java#L520
   
   Given that in a unit test, we may not have explicit control over what actual NestedField object we get when we do assertEquals, is there a better way we can validate the NestedField object we get is as expected?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org