fix: correct UUIDType partition representation for BucketTransform

[dingo4dev]

Rationale for this change

Resolves#2002

Are these changes tested?

Tested Locally. Should add testcases for this later

Are there any user-facing changes?

[Fokko]

@dingo4dev Thanks for working on this!

It would be good to throw in a test as well. It can be a simple test in test_writes.py where you write to a bucket UUID table. It also looks like there linter is not happy, could you run make lint as well?

[Fokko]

@dingo4dev Again, thanks for working on this. As part of this review, I dug a bit deeper into the issues, and it looks like we're missing the Parquet LogicalTypeAnnotation (apache/arrow#46469) which causes interoperability issues with other readers.

[dingo4dev]

@Fokko Thank you for taking the time to review. I appreciate your thoughtful feedback and the effort you put into this. To fully support the UUID type, it looks like we'll need to wait for a new Arrow release (> 20.0.0). In the meantime, I’ll continue working on the test cases for my commits.

[Fokko]

@dingo4dev Yes, please do. My biggest concern is that we produce Parquet files that will not be supported by other implementations because of the missing logical annotation. Arrow releases pretty often, so it can be resolved within reasonable timespan.

[Fokko]

@dingo4dev Good news, it looks like this is fixed in the next release of Arrow: apache/arrow#45866

[dingo4dev]

@Fokko TBR, After running the test case, I found that the identity transform of uuid is not supported for writing, because the value is bytes. So I tried rewrite the Avro writer and other related components.

• The uuid is still storing bytes in parquet
• Changed the identity value to hex representation ec9b663b-062f-4200-a130-8de19c21b800 instead of bytes string value b'\xec\x9bf;\x06/B\x00\xa10\x8d\xe1\x9c!\xb8\x00'

data/uuid_bucket=0/uuid_identity=ec9b663b-062f-4200-a130-8de19c21b800
|- xxxxx.parquet
data/uuid_bucket=1/uuid_identity=5f473c64-dbeb-449b-bdfa-b6b4185b1bde
|- xxxxx.parquet

Not sure is that correct and compatible with other integration as I haven't tried partition the uuid with identity before in other projects.
However if this PR is accepted, we still need to rewrite other test cases related to UUID.

[dingo4dev]

They also noticed that kind of problem in (apache/iceberg#13087)

[dingo4dev]

Squash commits and update testcases for uuid writer

[Fokko]

BTW, I found the issue on the Java side: apache/iceberg#13324

[dingo4dev]

Closing this PR as the issue it addresses has been resolved and changed in another #2002