[112] Add a UUID Type #518

danielhumanmod · 2024-08-18T08:17:57Z

Important Read

Aim to address #112

What is the purpose of the pull request

Create a UUID type in OneType and handle it appropriately in all converters. Only Iceberg has a concept of a UUID and it is a fixed size byte array in the underlying parquet files. We should aim to preserve the metadata that this byte array came from a UUID for round trip conversions.

Brief change log

Add a UUID type in InternalType
Handle UUID internal type in Iceberg/Delta/Avro(for Hudi) Converters as a fixed-size byte array
Adding unit tests

Verify this pull request

This pull request is already covered by existing tests, all existing tests should pass

danielhumanmod · 2024-08-18T08:29:08Z

xtable-core/src/main/java/org/apache/xtable/avro/AvroSchemaConverter.java

+        // Convert to fixed 16-byte array since Avro does not support UUID natively
+        return finalizeSchema(
+            Schema.createFixed(internalSchema.getName(), internalSchema.getComment(), null, 16),
+            internalSchema);


This converter is currently used exclusively for Hudi target conversions. Are there any other components or processes that need to handle the UUID internal type for Hudi (like HudiPartitionValuesExtractor.java)?

Nothing else is coming to mind. For partitions, we only support the year/month/day/hour and identity transforms from Iceberg current so those partition functions would just pass through the value if I'm remembering correctly.

danielhumanmod · 2024-08-18T08:31:22Z

Do we need to handle UUID here for Hudi partition value? https://github.com/apache/incubator-xtable/blob/main/xtable-core/src/main/java/org/apache/xtable/hudi/HudiPartitionValuesExtractor.java#L160-L162

Like:

case FIXED:
case BYTES:
case UUID:
        parsedValue = valueAsString.getBytes(StandardCharsets.UTF_8);
        break;

danielhumanmod · 2024-08-18T08:32:40Z

TODO: Probably we need some tests for round trip conversions, like Iceberg -> Delta Lake -> Iceberg to verify that UUIDs remain consistent throughout the conversions

the-other-tim-brown · 2024-08-19T01:06:35Z

xtable-core/src/main/java/org/apache/xtable/avro/AvroSchemaConverter.java

@@ -435,6 +435,11 @@ private Schema fromInternalSchema(InternalSchema internalSchema, String currentP
            Schema.createFixed(
                internalSchema.getName(), internalSchema.getComment(), null, fixedSize),
            internalSchema);
+      case UUID:
+        // Convert to fixed 16-byte array since Avro does not support UUID natively


technically there is a logical type for UUID in recent versions of avro https://avro.apache.org/docs/1.10.0/spec.html#UUID, but this is mentioning it is really just an annotation on a string field.

the-other-tim-brown · 2024-08-19T01:10:48Z

xtable-core/src/main/java/org/apache/xtable/avro/AvroSchemaConverter.java

+      case UUID:
+        // Convert to fixed 16-byte array since Avro does not support UUID natively
+        return finalizeSchema(
+            Schema.createFixed(internalSchema.getName(), internalSchema.getComment(), null, 16),


Schema exposes an addProp method. We could try to add a prop here that allows us to determine that a fixed byte array should be treated as an UUID in XTable

technically there is a logical type for UUID in recent versions of avro https://avro.apache.org/docs/1.10.0/spec.html#UUID, but this is mentioning it is really just an annotation on a string field.

Schema exposes an addProp method. We could try to add a prop here that allows us to determine that a fixed byte array should be treated as an UUID in XTable

Already added corresponding Prop in latest commit, thanks for providing this context Tim!

the-other-tim-brown · 2024-08-19T01:15:41Z

Do we need to handle UUID here for Hudi partition value? https://github.com/apache/incubator-xtable/blob/main/xtable-core/src/main/java/org/apache/xtable/hudi/HudiPartitionValuesExtractor.java#L160-L162

Like:
case FIXED:
case BYTES:
case UUID:
        parsedValue = valueAsString.getBytes(StandardCharsets.UTF_8);
        break;

@danielhumanmod yes, let's add that

the-other-tim-brown · 2024-08-19T01:18:59Z

TODO: Probably we need some tests for round trip conversions, like Iceberg -> Delta Lake -> Iceberg to verify that UUIDs remain consistent throughout the conversions

@danielhumanmod we don't have any full round trip testing yet but I would like to see some added to our integration tests in the future. For this PR we can start by adding a UUID to the schema used by the Iceberg table generator that is used in ITConversionController

danielhumanmod · 2024-08-20T04:19:27Z

xtable-core/src/test/java/org/apache/xtable/iceberg/TestIcebergDataHelper.java

@@ -99,7 +99,9 @@ public class TestIcebergDataHelper {
          NestedField.optional(
              28, "timestamp_micros_nullable_field", Types.TimestampType.withZone()),
          NestedField.optional(
-              30, "timestamp_local_micros_nullable_field", Types.TimestampType.withoutZone()));
+              30, "timestamp_local_micros_nullable_field", Types.TimestampType.withoutZone()),
+          NestedField.optional(33, "uuid_field", Types.UUIDType.get())


Hi @the-other-tim-brown ,After adding the new line to COMMON_FIELDS, I encountered an error when converting from Iceberg to Hudi during the ITConversionController test. I’m wondering if this issue might be due to a missing configuration (like need to updated the generated datasource somewhere?) or if there is something specific I should be aware of in this context.

If you could provide some guidance or context on this, it would be greatly appreciated.

Caused by: org.apache.spark.sql.AnalysisException: Illegal Parquet type: FIXED_LEN_BYTE_ARRAY (UUID). at org.apache.spark.sql.errors.QueryCompilationErrors$.illegalParquetTypeError(QueryCompilationErrors.scala:1762) at org.apache.spark.sql.execution.datasources.parquet.ParquetToSparkSchemaConverter.illegalType$1(ParquetSchemaConverter.scala:206) at org.apache.spark.sql.execution.datasources.parquet.ParquetToSparkSchemaConverter.$anonfun$convertPrimitiveField$2(ParquetSchemaConverter.scala:310) at scala.Option.getOrElse(Option.scala:189) at org.apache.spark.sql.execution.datasources.parquet.ParquetToSparkSchemaConverter.convertPrimitiveField(ParquetSchemaConverter.scala:224) at org.apache.spark.sql.execution.datasources.parquet.ParquetToSparkSchemaConverter.convertField(ParquetSchemaConverter.scala:187) at org.apache.spark.sql.execution.datasources.parquet.ParquetToSparkSchemaConverter.$anonfun$convertInternal$3(ParquetSchemaConverter.scala:147) at org.apache.spark.sql.execution.datasources.parquet.ParquetToSparkSchemaConverter.$anonfun$convertInternal$3$adapted(ParquetSchemaConverter.scala:117) at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:286) at scala.collection.immutable.Range.foreach(Range.scala:158) at scala.collection.TraversableLike.map(TraversableLike.scala:286) at scala.collection.TraversableLike.map$(TraversableLike.scala:279) at scala.collection.AbstractTraversable.map(Traversable.scala:108) at org.apache.spark.sql.execution.datasources.parquet.ParquetToSparkSchemaConverter.convertInternal(ParquetSchemaConverter.scala:117) at org.apache.spark.sql.execution.datasources.parquet.ParquetToSparkSchemaConverter.convert(ParquetSchemaConverter.scala:87) at org.apache.spark.sql.execution.datasources.parquet.HoodieParquetFileFormatHelper$.buildImplicitSchemaChangeInfo(HoodieParquetFileFormatHelper.scala:31) at org.apache.spark.sql.execution.datasources.parquet.Spark34LegacyHoodieParquetFileFormat.$anonfun$buildReaderWithPartitionValues$2(Spark34LegacyHoodieParquetFileFormat.scala:254) at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.org$apache$spark$sql$execution$datasources$FileScanRDD$$anon$$readCurrentFile(FileScanRDD.scala:231) at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.nextIterator(FileScanRDD.scala:293) at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.hasNext(FileScanRDD.scala:125) at scala.collection.Iterator$$anon$10.hasNext(Iterator.scala:460) at scala.collection.Iterator$$anon$10.hasNext(Iterator.scala:460) at org.apache.spark.shuffle.sort.BypassMergeSortShuffleWriter.write(BypassMergeSortShuffleWriter.java:140) at org.apache.spark.shuffle.ShuffleWriteProcessor.write(ShuffleWriteProcessor.scala:59) at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:101) at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:53) at org.apache.spark.TaskContext.runTaskWithListeners(TaskContext.scala:161) at org.apache.spark.scheduler.Task.run(Task.scala:139) at org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Executor.scala:554) at org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1529) at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:557) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829)

I found relevant context in Spark sunchao/spark@feec791.

Based on the code in the convertPrimitiveField method, it seems that the Spark cannot read FIXED_LEN_BYTE_ARRAY fields with a UUID logical type annotation in Parquet.

It doesn't work as well:
NestedField.optional(33, "uuid_field", Types.FixedType.ofLength(16))

But if we add this field in this way, it works:

NestedField.optional(33, "uuid_field", Types.BinaryType.get())

Does Iceberg to Delta work as expected? If only Hudi is broken, we can list that as a limitation and make a test case for Iceberg to Delta for now.

Thank you for digging in and providing the context up front of what you have tested and where the issue is, less homework for me :)

Does Iceberg to Delta work as expected? If only Hudi is broken, we can list that as a limitation and make a test case for Iceberg to Delta for now.

The conversion from Iceberg to Delta success, but there is a diff in the result:

Iceberg: "uuid_field":"8135e4c4-ea58-4ace-a819-4f835cb2b721"

Delta: "uuid_field":"gTXkxOpYSs6oGU+DXLK3IQ=="

In fact these two data are the same(8135e4c4-ea58-4ace-a819-4f835cb2b721 equals 8135e4c4-ea58-4ace-a819-4f835cb2b721), but assertion fails in this diff because the data format in two table is different - Iceberg supports UUIDs directly, while Delta represents them as binary.

Should we consider adding special comparison logic in checkDatasetEquivalence for these specific cases?

Thank you for digging in and providing the context up front of what you have tested and where the issue is, less homework for me :)

My pleasure :) @the-other-tim-brown , this is a great opportunity for me to learn more about Spark and Parquet. Additionally, if we determine that this issue is indeed caused by incomplete support for UUIDs in the Spark Parquet converter, we could potentially contribute some code to the Spark community.

I think we can add in a special case on the assertion for these UUIDs. Are you thinking of just adding a transform on the field in the dataset?

Does Iceberg to Delta work as expected? If only Hudi is broken, we can list that as a limitation and make a test case for Iceberg to Delta for now.

I think we can add in a special case on the assertion for these UUIDs. Are you thinking of just adding a transform on the field in the dataset?

Thanks for the feedback @the-other-tim-brown , in the latest commit, I have completed testing for UUID:

Add a UUID test case for Iceberg -> Delta for now

Add special case on assertion by processing binary UUID into string before comparison

Make "xtableLogicalType" into a constant

the-other-tim-brown · 2024-08-22T00:58:34Z

xtable-core/src/main/java/org/apache/xtable/avro/AvroSchemaConverter.java

+      case UUID:
+        Schema uuidSchema =
+            Schema.createFixed(internalSchema.getName(), internalSchema.getComment(), null, 16);
+        uuidSchema.addProp("logicalType", "uuid");


This is going to be confusing to someone without knowledge of XTable being involved since logicalType is an existing concept and there is a logical type with a string base type in avro. We should make it prefixed with xtable or something like that so someone looking at the schema in Hudi commit is aware that this is some special context

This is going to be confusing to someone without knowledge of XTable being involved since logicalType is an existing concept and there is a logical type with a string base type in avro. We should make it prefixed with xtable or something like that so someone looking at the schema in Hudi commit is aware that this is some special context

Thanks for the feedback! Already replace the prop with "xtableLogicalType" in the latest commit!=

the-other-tim-brown · 2024-08-22T01:00:18Z

xtable-core/src/main/java/org/apache/xtable/delta/DeltaSchemaExtractor.java

@@ -90,6 +90,7 @@ private DataType convertFieldType(InternalField field) {
        return DataTypes.LongType;
      case BYTES:
      case FIXED:
+      case UUID:


There is some metadata you an add to a field if I am remember correctly, we will want to pack some context about the fact that this is a UUID if possible

There is some metadata you an add to a field if I am remember correctly, we will want to pack some context about the fact that this is a UUID if possible

That's a good catch, I added "xtableLogicalType" in metadata in latest commit

xtable-core/src/main/java/org/apache/xtable/delta/DeltaSchemaExtractor.java

the-other-tim-brown · 2024-08-29T02:31:17Z

xtable-core/src/main/java/org/apache/xtable/avro/AvroSchemaConverter.java

@@ -132,8 +132,13 @@ private InternalSchema toInternalSchema(
          break;
        }
        if (schema.getType() == Schema.Type.FIXED) {
-          metadata.put(InternalSchema.MetadataKey.FIXED_BYTES_SIZE, schema.getFixedSize());
-          newDataType = InternalType.FIXED;
+          String xtableLogicalType = schema.getProp("xtableLogicalType");


Can you put xtableLogicalType into a constant that we can reference in the other files as well?

the-other-tim-brown · 2024-08-29T02:32:01Z

xtable-core/src/main/java/org/apache/xtable/delta/DeltaSchemaExtractor.java

@@ -172,7 +186,11 @@ private InternalSchema toInternalSchema(
        type = InternalType.DOUBLE;
        break;
      case "binary":
-        type = InternalType.BYTES;
+        if ("uuid".equals(originalMetadata.getString("xtableLogicalType"))) {


the getString is failing when I run locally. I think there needs to be a contains check first or else you get this java.util.NoSuchElementException: key not found: xtableLogicalType

the getString is failing when I run locally. I think there needs to be a contains check first or else you get this java.util.NoSuchElementException: key not found: xtableLogicalType

Sorry, I have committed this changes locally but forget to push, already fixed in latest commit

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

xtable-core/src/test/java/org/apache/xtable/iceberg/TestIcebergDataHelper.java

the-other-tim-brown · 2024-09-09T14:06:18Z

@danielhumanmod apologies for the delay on this review. I was out of office for the last 10 days. Can you resolve the conflict that GitHub is flagging? I am also going to spend a little time trying to resolve the hudi side of the reader today in parallel to see if we just need some property set on the reader.

danielhumanmod · 2024-09-10T05:41:47Z

@danielhumanmod apologies for the delay on this review. I was out of office for the last 10 days. Can you resolve the conflict that GitHub is flagging? I am also going to spend a little time trying to resolve the hudi side of the reader today in parallel to see if we just need some property set on the reader.

Thanks Tim! Sure, I have solved the conflict in latest commit. And appreciate your time to help on the Hudi issue!

the-other-tim-brown · 2024-09-18T14:30:30Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

+    List<Arguments> arguments = new ArrayList<>();
+    for (SyncMode syncMode : SyncMode.values()) {
+      for (boolean isPartitioned : new boolean[] {true, false}) {
+        // TODO: Add Hudi UUID support later


Can you create an issue for this in the project so we don't forget?

Can you create an issue for this in the project so we don't forget?

Sure, I have created an issue for this problem: #543

Can you reference the issue in the comment as well?

the-other-tim-brown · 2024-09-18T14:31:18Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

@@ -261,6 +281,94 @@ public void testVariousOperations(
    }
  }

+  // The test content is the same as testVariousOperations


Since this is only testing end to end UUID support, we can limit the amount of commits and keep this test smaller

Since this is only testing end to end UUID support, we can limit the amount of commits and keep this test smaller

Thanks for the suggestion, have simplified it in latest commit :)

the-other-tim-brown · 2024-09-19T00:58:54Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

+          sourceTableFormat, table, targetTableFormats, table.getFilterQuery());
+    }
+
+    try (GenericTable tableWithUpdatedSchema =


I think we can drop this as well. In the other testing, we the second try-with-resources is due to a change in schema in the source table so we test schema evolution but that is not being tested here. Let me know if I am missing something

I think we can drop this as well. In the other testing, we the second try-with-resources is due to a change in schema in the source table so we test schema evolution but that is not being tested here. Let me know if I am missing something

Thanks for sharing this context, Tim. Yeah this part can be removed.

the-other-tim-brown · 2024-09-19T01:01:22Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

+    Gson gson = new Gson();
+    JsonParser parser = new JsonParser();


We use jackson in other places for json, can we use that here to avoid requiring another library in case our dependencies change in the future?

We use jackson in other places for json, can we use that here to avoid requiring another library in case our dependencies change in the future?

Sure, thanks for the context! Already replaced that in latest commit.

the-other-tim-brown · 2024-09-19T01:02:02Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

+                JsonElement value = jsonObject.get(key);
+                // Check if the key is "uuid_field" and if the value is Base64 encoded
+                if (key.equals("uuid_field")
+                    && value.getAsString().matches("^[A-Za-z0-9+/]+={0,2}$")) {


matches will keep recompiling the regex here. We can compile the pattern and define it as a constant for reuse to be slightly more efficient

the-other-tim-brown · 2024-09-19T01:02:28Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

+                  jsonObject.addProperty(key, uuid.toString());
+                }
+              }
+              return gson.toJson(jsonObject);


Just want to sanity check that this will maintain the field ordering. If not, we could get some flakey tests in the future

the-other-tim-brown

@danielhumanmod After addressing these last minor issues, can you squash down to a single commit for me so it is ready to merge after the test complete?

the-other-tim-brown · 2024-09-20T02:17:08Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

+  // converting Base64-encoded UUID fields from Delta to their UUID string representations for
+  // testing
+  private List<String> processUUID(List<String> rows) {
+    ObjectMapper objectMapper = new ObjectMapper();


The instance is thread safe so you can define a static constant for this in the test class

the-other-tim-brown · 2024-09-20T02:17:42Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

@@ -100,6 +108,8 @@ public class ITConversionController {
  @TempDir public static Path tempDir;
  private static final DateTimeFormatter DATE_FORMAT =
      DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS").withZone(ZoneId.of("UTC"));
+  // Compile the Base64 regex pattern once for reuse
+  private static final Pattern BASE64_PATTERN = Pattern.compile("^[A-Za-z0-9+/]+={0,2}$");


Can you add UUID to the name so it's clear what it is the base 64 version of?

danielhumanmod · 2024-09-20T08:20:23Z

Hi @the-other-tim-brown , I’ve addressed all the issues mentioned in the previous comments and have squashed all the commits into one.

Additionally, I’ve refined the comparison logic in checkDatasetEquivalence to make it less invasive to the existing code. Now, the UUID-specific comparison only applies to datasets containing UUID fields, which also resolves the ordering issue.

Thank you so much for your detailed review and suggestions—they were incredibly helpful!

the-other-tim-brown · 2024-09-23T01:53:04Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

+      String row1 = dataset1Rows.get(i);
+      String row2 = dataset2Rows.get(i);


We're no longer asserting that the other fields are also equivalent. Is there a way we can do that as well?

We're no longer asserting that the other fields are also equivalent. Is there a way we can do that as well?

Apologies for missing that earlier. You’re right—we do need to compare the other fields as well. This has already been fixed in the latest commit.

the-other-tim-brown · 2024-09-23T01:54:02Z

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java

@@ -103,6 +109,7 @@ public class ITConversionController {

  private static JavaSparkContext jsc;
  private static SparkSession sparkSession;
+  private static final ObjectMapper objectMapper = new ObjectMapper();


use UPPER_UNDERSCORE when defining constants and move this up to line 109 to group with the DATE_FORMAT

use UPPER_UNDERSCORE when defining constants and move this up to line 109 to group with the DATE_FORMAT

Done! Thanks for the suggestion

the-other-tim-brown

Thank you for your contribution!

danielhumanmod · 2024-09-23T16:11:01Z

Thank you for your contribution!

Thank you so much for your detailed review and approval, @the-other-tim-brown ! Your feedback helped me improve the changes, and I learned a lot from the process. I’m really looking forward to contributing more to the project and continuing to collaborate with you in the future.

danielhumanmod commented Aug 18, 2024

View reviewed changes

danielhumanmod mentioned this pull request Aug 18, 2024

Add a UUID type #112

Closed

the-other-tim-brown reviewed Aug 19, 2024

View reviewed changes

danielhumanmod commented Aug 20, 2024

View reviewed changes

the-other-tim-brown reviewed Aug 22, 2024

View reviewed changes

danielhumanmod commented Aug 22, 2024

View reviewed changes

xtable-core/src/main/java/org/apache/xtable/delta/DeltaSchemaExtractor.java Show resolved Hide resolved

the-other-tim-brown reviewed Aug 29, 2024

View reviewed changes

danielhumanmod commented Sep 3, 2024

View reviewed changes

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java Show resolved Hide resolved

danielhumanmod commented Sep 3, 2024

View reviewed changes

xtable-core/src/test/java/org/apache/xtable/ITConversionController.java Show resolved Hide resolved

danielhumanmod commented Sep 3, 2024

View reviewed changes

xtable-core/src/test/java/org/apache/xtable/iceberg/TestIcebergDataHelper.java Show resolved Hide resolved

the-other-tim-brown reviewed Sep 18, 2024

View reviewed changes

the-other-tim-brown reviewed Sep 19, 2024

View reviewed changes

the-other-tim-brown reviewed Sep 20, 2024

View reviewed changes

danielhumanmod force-pushed the 112-support-uuid-type branch 9 times, most recently from 4977ab9 to 04b2ce2 Compare September 20, 2024 07:36

danielhumanmod force-pushed the 112-support-uuid-type branch from 5c4f3dd to 79ba61c Compare September 20, 2024 08:05

the-other-tim-brown reviewed Sep 23, 2024

View reviewed changes

Support UUID type when iceberg to delta

a8664fd

danielhumanmod force-pushed the 112-support-uuid-type branch from 79ba61c to a8664fd Compare September 23, 2024 05:24

the-other-tim-brown approved these changes Sep 23, 2024

View reviewed changes

the-other-tim-brown merged commit a0d86a8 into apache:main Sep 23, 2024
2 checks passed

vinishjail97 mentioned this pull request Oct 3, 2024

XTable 2nd release #551

Open

2 tasks

		Gson gson = new Gson();
		JsonParser parser = new JsonParser();

		String row1 = dataset1Rows.get(i);
		String row2 = dataset2Rows.get(i);

[112] Add a UUID Type #518

[112] Add a UUID Type #518

Conversation

danielhumanmod commented Aug 18, 2024

Important Read

What is the purpose of the pull request

Brief change log

Verify this pull request

danielhumanmod Aug 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielhumanmod commented Aug 18, 2024

danielhumanmod commented Aug 18, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

the-other-tim-brown commented Aug 19, 2024

the-other-tim-brown commented Aug 19, 2024 • edited Loading

danielhumanmod Aug 20, 2024 • edited Loading

Choose a reason for hiding this comment

danielhumanmod Aug 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielhumanmod Aug 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielhumanmod Sep 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielhumanmod Aug 31, 2024 • edited Loading

Choose a reason for hiding this comment

the-other-tim-brown commented Sep 9, 2024

danielhumanmod commented Sep 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

the-other-tim-brown left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielhumanmod commented Sep 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

the-other-tim-brown left a comment

Choose a reason for hiding this comment

danielhumanmod commented Sep 23, 2024

danielhumanmod Aug 18, 2024 •

edited

Loading

the-other-tim-brown commented Aug 19, 2024 •

edited

Loading

danielhumanmod Aug 20, 2024 •

edited

Loading

danielhumanmod Aug 20, 2024 •

edited

Loading

danielhumanmod Aug 22, 2024 •

edited

Loading

danielhumanmod Sep 3, 2024 •

edited

Loading

danielhumanmod Aug 31, 2024 •

edited

Loading

danielhumanmod commented Sep 20, 2024 •

edited

Loading