Core: Interface based DataFile reader and writer API #12298

pvary · 2025-02-17T15:03:50Z

Instead of base classes, just use interfaces

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java

snazy · 2025-02-18T15:52:38Z

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java

+    public Key(FileFormat fileFormat, String dataType, String builderType) {
+      this.fileFormat = fileFormat;
+      this.dataType = dataType;
+      this.builderType = builderType;


I was thinking of defining the default one using a priority (int) based approach and let the one with the highest priority be the default one. WDYT?

We have a concrete example for this: Comet vectorized parquet reader spark.sql.iceberg.parquet.reader-type

I think it is good if the reader/writer choice is a conscious decision, and not happening based on some behind the scenes algorithm.

+1 for simplicity. This code should not determine things like whether Comet is used. This should have a single purpose, which is to standardize how object models plug in.

Moved the config to properties, and the builder method will create the different readers based on this config

snazy · 2025-02-18T15:56:34Z

core/src/main/java/org/apache/iceberg/io/datafile/AppenderBuilder.java

+import org.apache.iceberg.io.FileAppender;
+
+/** Builder API for creating {@link FileAppender}s. */
+public interface AppenderBuilder extends InternalData.WriteBuilder {


Wonder that AppenderBuilder has a base interface but the other builders don't.
Guess it might help to have a common DataFileIoBuilder interface defining the common builder attributes (table, schema, properties, meta). It's a bit of an "adventure in Java generics", but doable.

If you take a look at the other PRs (#12164, #12069), you can see that first, I took that adventurous route, but the result was too many classes/interfaces and casts.

This PR is aiming for the minimal set of changes, and the InternalData.WriteBuilder is already introduced to Iceberg by #12060. We either need to widen that interface or inherit from it here.

I'm also confused by this inheritance. We're extending but overriding everything and it's not clear to me what we really gain by going with this approach. It looks like it ends up as a completely different builder that produces the same build result.

The goal with the PR was to show the minimal changes required to make the idea work.
We either create a different builder class for the InternalData.WriteBuilder and the DataFile.WriteBuilder, or we need to have inheritance of the interfaces.

Based on our discussion below we might end up using a different strategy, so revisit this comment later.

snazy · 2025-02-18T15:57:46Z

data/src/main/java/org/apache/iceberg/data/GenericReader.java

+    return DataFileServiceRegistry.read(
+            task.file().format(), Record.class.getName(), input, fileProjection, partition)
+        .split(task.start(), task.length())
+        .caseSensitive(caseSensitive)
+        .reuseContainers(reuseContainers)
+        .filter(task.residual())
+        .build();


I like these simplifications!

liurenjie1024

Thanks @pvary for this proposal, I left some comments.

liurenjie1024 · 2025-02-21T09:55:30Z

core/src/main/java/org/apache/iceberg/io/datafile/ReaderBuilder.java

+
+  /** Enables reusing the containers returned by the reader. Decreases pressure on GC. */
+  @Override
+  default ReaderBuilder reuseContainers() {


Seems it should not be here? These are parquet reader specific.

It is also used by Avro.
See:

iceberg/core/src/main/java/org/apache/iceberg/avro/AvroIterable.java

Line 51 in 604422b

this.reuseContainers = reuseContainers;

liurenjie1024 · 2025-02-21T09:57:56Z

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java

+   * @param rowType of the native input data
+   * @return {@link DataWriterBuilder} for building the actual writer
+   */
+  public static <S> DataWriterBuilder dataWriterBuilder(


I don't quite understand in what case need this? I think append would be enough?

I will check this. We might be able to remove this.

Based on the current approach, the file format api implementation creates the appender, and the PR creates the writers for the different data/delete files

liurenjie1024 · 2025-02-21T09:59:32Z

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java

+   * @return {@link AppenderBuilder} for building the actual writer
+   */
+  public static <S, B extends EqualityDeleteWriterBuilder<B>>
+      EqualityDeleteWriterBuilder<B> equalityDeleteWriterBuilder(


I don't think file format should consider eqaulity deletion/pos deletion here.

Current Avro positional delete writer behaves differently than Parquet/ORC positional delete writers.
In case of the positional delete files the schema provided to the Avro writer should omit the PATH and the POS fields, and only needs the actual table schema. The writer handles the PATH/POS fields by static code:

iceberg/core/src/main/java/org/apache/iceberg/avro/Avro.java

Lines 614 to 618 in b8fdd84

public void write(PositionDelete<D> delete, Encoder out) throws IOException {

PATH_WRITER.write(delete.path(), out);

POS_WRITER.write(delete.pos(), out);

rowWriter.write(delete.row(), out);

}

The Parquet/ORC positional delete writers behave in the same way. They expect the same input.

If we are ready for a more invasive change we can harmonize the writers.
I have aimed for a minimal changeset to allow easier acceptance for the PR.

The appender doesn't need to know about these, but the file formats and the writer implementations need this

liurenjie1024 · 2025-02-21T10:04:29Z

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java

+   * issues.
+   */
+  private static final class Registry {
+    private static final Map<Key, ReaderService> READ_BUILDERS = Maps.newConcurrentMap();


This is more like a convention problem, I think maybe we just need to store in FileFormatService in registry?

Sometimes we don't have writers (arrow), or we have multiple readers vectorized/non-vectorized readers. Also Parquet has Comet reader. So I kept the writers and the readers separate

liurenjie1024 · 2025-02-21T10:05:38Z

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java

+  /** Key used to identify readers and writers in the {@link DataFileServiceRegistry}. */
+  public static class Key {
+    private final FileFormat fileFormat;
+    private final String dataType;


Is this things like arrow, internal row?

Yeah,
Currenly we have:

Record - generic readers/writers

ColumnarBatch (arrow) - arrow

RowData - Flink

InternalRow - Spark

ColumnarBatch (spark) - Spark batch

pvary · 2025-02-21T14:10:03Z

I will start to collect the differences here between the different writer types (appender/dataWriter/equalityDeleteWriter/positionalDeleteWriter) for reference:

Writer context is different between delete and data files. This contains TableProperties/Configurations which could be different between delete and data files. For example for parquet: RowGroupSize/PageSize/PageRowLimit/DictSize/Compression etc. For ORC and Avro we have some similar changing configs
Specific writer functions for position deletes to write out the PositionDelete records
Positional delete PathTransformFunction to convert writer data type for the path to file format data type

danielcweeks · 2025-02-21T19:31:33Z

core/src/main/java/org/apache/iceberg/io/datafile/DataWriterBuilder.java

+import org.apache.iceberg.io.DataWriter;
+
+/** Builder API for creating {@link DataWriter}s. */
+public interface DataWriterBuilder {


Why not put the builder interface into the DataWriter class and put it in the same package? It seems odd to me that we're introducing this new datafile package.

The classes which has to be implemented by the file formats are kept in the io package, but moved the others to the data package

core/src/main/java/org/apache/iceberg/avro/Avro.java

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java

...urces/META-INF/services/org.apache.iceberg.io.datafile.DataFileServiceRegistry$WriterService

rdblue · 2025-02-22T00:10:36Z

While I think the goal here is a good one, the implementation looks too complex to be workable in its current form.

The primary issue that we currently have is adapting object models (like Iceber's internal StructLike, Spark's InternalRow, or Flink's RowData) to file formats so that you can separately write object model to format glue code and have it work throughout support for an engine. I think a diff from the InternalData PR demonstrates it pretty well:

-    switch (format) {
-      case AVRO:
-        AvroIterable<ManifestEntry<F>> reader =
-            Avro.read(file)
-                .project(ManifestEntry.wrapFileSchema(Types.StructType.of(fields)))
-                .createResolvingReader(this::newReader)
-                .reuseContainers()
-                .build();
+    CloseableIterable<ManifestEntry<F>> reader =
+        InternalData.read(format, file)
+            .project(ManifestEntry.wrapFileSchema(Types.StructType.of(fields)))
+            .reuseContainers()
+            .build();
 
-        addCloseable(reader);
+    addCloseable(reader);
 
-        return CloseableIterable.transform(reader, inheritableMetadata::apply);
+    return CloseableIterable.transform(reader, inheritableMetadata::apply);
-
-      default:
-        throw new UnsupportedOperationException("Invalid format for manifest file: " + format);
-    }

This shows:

Rather than a switch, the format is passed to create the builder
There is no longer a callback passed to create readers for the object model (createResolvingReader)

In this PR, there are a lot of other changes as well. I'm looking at one of the simpler Spark cases in the row reader.

The builder is initialized from DataFileServiceRegistry and now requires a format, class name, file, projection, and constant map:

    return DataFileServiceRegistry.readerBuilder(
            format, InternalRow.class.getName(), file, projection, idToConstant)

There are also new static classes in the file. Each creates a new service and each service creates the builder and object model:

  public static class AvroReaderService implements DataFileServiceRegistry.ReaderService {
    @Override
    public DataFileServiceRegistry.Key key() {
      return new DataFileServiceRegistry.Key(FileFormat.AVRO, InternalRow.class.getName());
    }

    @Override
    public ReaderBuilder builder(
        InputFile inputFile,
        Schema readSchema,
        Map<Integer, ?> idToConstant,
        DeleteFilter<?> deleteFilter) {
      return Avro.read(inputFile)
          .project(readSchema)
          .createResolvingReader(schema -> SparkPlannedAvroReader.create(schema, idToConstant));
    }

The createResolvingReader line is still there, just moved into its own service class instead of in branches of a switch statement.

In addition, there are now a lot more abstractions:

A builder for creating an appender for a file format
A builder for creating a data file writer for a file format
A builder for creating an equality delete writer for a file format
A builder for creating a position delete writer for a file format
A builder for creating a reader for a file format
A "service" registry (what is a service?)
A "key"
A writer service
A reader service

I think that the next steps are to focus on making this a lot simpler, and there are some good ways to do that:

Focus on removing boilerplate and hiding the internals. For instance, Key, if needed, should be an internal abstraction and not complexity that is exposed to callers
The format-specific data and delete file builders typically wrap an appender builder. Is there a way to handle just the reader builder and appender builder?
Is the extra "service" abstraction helpful?
Remove ServiceLoader and use a simpler solution. I think that formats could simply register themselves like we do for InternalData. I think it would be fine to have a trade-off that Iceberg ships with a list of known formats that can be loaded, and if you want to replace that list it's at your own risk.
Standardize more across the builders for FileFormat. How idToConstant is handled is a good example. That should be passed to the builder instead of making the whole API more complicated. Projection is the same.

pvary · 2025-02-24T10:34:16Z

While I think the goal here is a good one, the implementation looks too complex to be workable in its current form.

I'm happy that we agree with the goals. I created a PR to start the conversation. If there are willing reviewers we can introduce more invasive changes to archive a better API. I'm all for it!

The primary issue that we currently have is adapting object models (like Iceber's internal StructLike, Spark's InternalRow, or Flink's RowData) to file formats so that you can separately write object model to format glue code and have it work throughout support for an engine.

I think we need to keep this direct transformations to prevent the performance loss which would be caused by multiple transformations between object model -> common model -> file format.

We have a matrix of transformation which we need to encode somewhere:

Source	Target
Parquet	StructLike
Parquet	InternalRow
Parquet	RowData
Parquet	Arrow
Avro	...
ORC	...

[..]

Rather than a switch, the format is passed to create the builder

There is no longer a callback passed to create readers for the object model (createResolvingReader)

The InternalData reader has one advantage over the data file readers/writers. The internal object model is static for these readers/writers. For the DataFile readers/writers we have multiple object models to handle.

[..]
I think that the next steps are to focus on making this a lot simpler, and there are some good ways to do that:

Focus on removing boilerplate and hiding the internals. For instance, Key, if needed, should be an internal abstraction and not complexity that is exposed to callers

If we allow adding new builders for the file formats we can remove a good chunk of the boilerplate code. Let me see how this would look like

The format-specific data and delete file builders typically wrap an appender builder. Is there a way to handle just the reader builder and appender builder?

We need to refactor the Avro positional delete write for this, or add a positionalWriterFunc. Also need to consider that the format specific configurations which are different for the appenders and the delete files (DELETE_PARQUET_ROW_GROUP_SIZE_BYTES vs. PARQUET_ROW_GROUP_SIZE_BYTES)

Is the extra "service" abstraction helpful?

If we are ok with having a new Builder for the readers/writers, then we don't need the service. It was needed to keep the current APIs and the new APIs compatible.

Remove ServiceLoader and use a simpler solution. I think that formats could simply register themselves like we do for InternalData. I think it would be fine to have a trade-off that Iceberg ships with a list of known formats that can be loaded, and if you want to replace that list it's at your own risk.

Will do

Standardize more across the builders for FileFormat. How idToConstant is handled is a good example. That should be passed to the builder instead of making the whole API more complicated. Projection is the same.

Will see what could be arcived

rdblue · 2025-03-14T18:17:21Z

spark/v3.5/spark/src/main/java/org/apache/iceberg/spark/source/DataFileServices.java

+        outputFile ->
+            Avro.write(outputFile)
+                .writerFunction(
+                    (schema, engineSchema) -> new SparkAvroWriter((StructType) engineSchema))


Why is there a cast here if the builder is parameterized by this type?

Had to make Avro.WriteBuilder parametrized. Created a deprecation and new classes to make this work. Added serious size to the PR.
Please check, and if you think it is worth it, then we can keep

rdblue · 2025-03-14T18:17:46Z

spark/v3.5/spark/src/main/java/org/apache/iceberg/spark/source/DataFileServices.java

+            ORC.write(outputFile)
+                .writerFunction(
+                    (schema, messageType, engineSchema) -> new SparkOrcWriter(schema, messageType))
+                .pathTransformFunc(path -> UTF8String.fromString(path.toString())));


What is this?

The delete writer needs this to convert the path to strings in the delete records.
All of these are file format specific, so I think this should be fine here as this is not exposed to the users

rdblue · 2025-03-14T18:22:22Z

data/src/main/java/org/apache/iceberg/data/RegistryBasedFileWriterFactory.java

+    try {
+      return DataFileServiceRegistry.writeBuilder(deleteFileFormat, inputType, file)
+          .set(properties)
+          .set(writeProperties)


This doesn't seem right. Why are table and write properties both being set?

This is how it is done currently. Just the set calls are in different methods (SparkFileWriterFactory for the writeProperties and for the actual table properties)

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java

core/src/main/java/org/apache/iceberg/io/datafile/WriteBuilder.java

rdblue · 2025-03-14T18:43:30Z

core/src/main/java/org/apache/iceberg/io/datafile/WriteBuilder.java

+   * @param properties a map of writer config properties
+   * @return this for method chaining
+   */
+  public WriteBuilder<A, E> set(Map<String, String> properties) {


Is this set in other builders or could we use setAll?

This was a hard decision.
We have meta(String, String), and meta(Map), set(String,String) in the InternalData. We have set(String, String) and setAll(Map) in the current writers. I opted for consistency in the new API, and went for set. Since it is a new API, I think better to be consistent

rdblue · 2025-03-14T18:44:34Z

core/src/main/java/org/apache/iceberg/io/datafile/WriteBuilder.java

+
+  /** Sets the metrics configuration used for collecting column metrics for the created file. */
+  public WriteBuilder<A, E> metricsConfig(MetricsConfig newMetricsConfig) {
+    appenderBuilder.metricsConfig(newMetricsConfig);


Is this ever customized? Can we set it automatically from table properties?

The current GenericAppenderFactory customizes it for backward compatibility reasons.
I'm not sure requiring a full table object as a parameter is better anyways.. (I just removed based on your suggestion 😄)

core/src/main/java/org/apache/iceberg/io/datafile/WriteBuilder.java

rdblue · 2025-03-14T18:48:34Z

core/src/main/java/org/apache/iceberg/io/datafile/WriteBuilder.java

+  }
+
+  /** Sets the equality field ids for the equality delete writer. */
+  public WriteBuilder<A, E> withEqualityFieldIds(List<Integer> fieldIds) {


What is the relationship between this builder and the builder for data or delete files? Do we need to pass this here?

I think the latest changes may have gone too far in combining interfaces. I think the object models should handle appender builders and those builders should be used by a data file builders and delete file builders that are shared. Combining the delete and data file builders creates confusing options, like this for a data file builder.

Split up the Writer API interfaces (kept the single writer implementation for code simplicity reasons)

snazy

Just left some comments, nothing that's really blocking

snazy · 2025-03-18T14:38:13Z

core/src/main/java/org/apache/iceberg/avro/Avro.java

@@ -287,14 +405,17 @@ CodecFactory codec() {
    }
  }

+  @Deprecated


Are these just deprecated or deprecated-for-removal?

Definitely deprecated for removal, but not sure about the timing of the PR. Also they are used pretty extensively in tests, which we need to check later.

Based on @danielcweeks comments on the community sync we can remove after 1 minor release, so when we are near to finalizing the PR, I will add the javadoc comments based on this.

core/src/main/java/org/apache/iceberg/avro/Avro.java

data/src/main/java/org/apache/iceberg/data/GenericFileWriterFactory.java

core/src/main/java/org/apache/iceberg/io/datafile/DataFileToObjectModelRegistry.java

flink/v1.20/flink/src/main/java/org/apache/iceberg/flink/data/FlinkObjectModels.java

core/src/main/java/org/apache/iceberg/io/datafile/DataFileToObjectModelRegistry.java

snazy · 2025-03-18T15:05:12Z

core/src/main/java/org/apache/iceberg/io/datafile/WriterBuilderBase.java

+ * @param <B> type of the builder
+ * @param <E> engine specific schema of the input records used for appender initialization
+ */
+interface WriterBuilderBase<B extends WriterBuilderBase<B, E>, E> {


Wonder if this interface should be public, or it's functions explicitly overridden in the public interfaces that extend this one - to avoid potential visibility issues.

I prefer to keep make interfaces public only if they could be directly called.
The interfaces are created only to remove code duplication. I'm actually considering removing them, and directly copying the methods to the public interfaces, but I don't have a strong preference here.

snazy · 2025-03-18T15:06:38Z

core/src/main/java/org/apache/iceberg/io/datafile/WriteBuilder.java

+ * @param <E> engine specific schema of the input records used for appender initialization
+ */
+@SuppressWarnings("unchecked")
+class WriteBuilder<B extends WriteBuilder<B, A, E>, A extends DataFileAppenderBuilder<A, E>, E>


Nit: rename to WriteBuilderImpl to distinguish it e.g. from the public ReadBuilder interface.

This is again an interesting question. We have 2 different apis here:

APIs implemented by the file formats - currently in the core module and in the org.apache.iceberg.io package

APIs used by the data file readers and writers - currently in the data module in the org.apache.iceberg.data package

The ReadBuilder is an exception, because it is implemented by the file format, but directly exposed to the readers. I was considering creating a wrapper around it to decouple the two. I decided against it, because I don't see any direct current benefit from it and it makes harder to expose the SupportsDeleteFilter api through the 2 interfaces.

pvary · 2025-03-19T15:02:52Z

Here are a few important open questions:

We should decide on the expected filtering behavior. Currently the filters are applied as best effort for the file format readers. We might decide on more strict behavior, and enforce the file formats to apply all filters when provided. I would suggest to do it in another PR even if we chose to change current state.
Batch sizes are currently parameters which could be set for non-vectorized readers too. We could put the batch size as a reader property, and tell the readers to parse the reader properties when batch read happens. I would prefer the current solution as the expectation for the readers is self documented.
Parquet/Orc configuration. Currently the Spark batch reader uses different configuration objects for Parquet and ORC as requested by @aokolnychyi. @rdblue suggested to use a common configuration instead. I'm still learning the Spark code, so I don't have a strong opinion here

…filters

github-actions bot added spark parquet arrow core data flink ORC labels Feb 17, 2025

pvary force-pushed the file_Format_api_without_base branch 6 times, most recently from 907089c to 313c2d5 Compare February 18, 2025 09:13

snazy reviewed Feb 18, 2025

View reviewed changes

pvary force-pushed the file_Format_api_without_base branch 2 times, most recently from c528a52 to 9975b4f Compare February 20, 2025 09:45

pvary changed the title ~~WIP: Interface based FileFormat API~~ WIP: Interface based DataFile reader and writer API Feb 20, 2025

liurenjie1024 reviewed Feb 21, 2025

View reviewed changes

danielcweeks reviewed Feb 21, 2025

View reviewed changes

core/src/main/java/org/apache/iceberg/avro/Avro.java Outdated Show resolved Hide resolved

danielcweeks reviewed Feb 21, 2025

View reviewed changes

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java Outdated Show resolved Hide resolved

rdblue reviewed Feb 21, 2025

View reviewed changes

...urces/META-INF/services/org.apache.iceberg.io.datafile.DataFileServiceRegistry$WriterService Outdated Show resolved Hide resolved

pvary force-pushed the file_Format_api_without_base branch 5 times, most recently from c488d32 to 71ec538 Compare February 25, 2025 16:53

rdblue reviewed Mar 14, 2025

View reviewed changes

danielcweeks reviewed Mar 14, 2025

View reviewed changes

core/src/main/java/org/apache/iceberg/io/datafile/DataFileServiceRegistry.java Outdated Show resolved Hide resolved

rdblue reviewed Mar 14, 2025

View reviewed changes

core/src/main/java/org/apache/iceberg/io/datafile/WriteBuilder.java Outdated Show resolved Hide resolved

rdblue reviewed Mar 14, 2025

View reviewed changes

core/src/main/java/org/apache/iceberg/io/datafile/WriteBuilder.java Outdated Show resolved Hide resolved

rdblue reviewed Mar 14, 2025

View reviewed changes

core/src/main/java/org/apache/iceberg/io/datafile/WriteBuilder.java Outdated Show resolved Hide resolved

rdblue reviewed Mar 14, 2025

View reviewed changes

pvary mentioned this pull request Mar 14, 2025

Just for running tests #12530

Open

pvary force-pushed the file_Format_api_without_base branch 2 times, most recently from 132d19b to 050b70a Compare March 18, 2025 14:05

snazy reviewed Mar 18, 2025

View reviewed changes

github-actions bot added the build label Mar 18, 2025

pvary force-pushed the file_Format_api_without_base branch 2 times, most recently from b460f91 to a549bda Compare March 19, 2025 09:57

pvary added 3 commits March 24, 2025 17:51

Proposed API interfaces

3c3f9d5

Highlight that the case-sensitivity for the readers are only for the …

0fca6e2

…filters

Move batch size to config

50ed143

pvary force-pushed the file_Format_api_without_base branch from a549bda to 50ed143 Compare March 24, 2025 18:06

pvary changed the title ~~WIP: Interface based DataFile reader and writer API~~ Core: Interface based DataFile reader and writer API Mar 25, 2025

Deprecation messages

c8e2e33

pvary force-pushed the file_Format_api_without_base branch from 6ba23be to c8e2e33 Compare March 26, 2025 12:34

pvary added 2 commits March 28, 2025 15:39

Register full object models

2c0e977

Javadoc fine tuning

e7b559c

github-actions bot added the MR label Mar 30, 2025

IcebergInputFormat moved ot ObjectModelRegistry

2e86ee9

pvary force-pushed the file_Format_api_without_base branch from 2ee67b3 to 2e86ee9 Compare March 30, 2025 21:07

	public void write(PositionDelete<D> delete, Encoder out) throws IOException {
	PATH_WRITER.write(delete.path(), out);
	POS_WRITER.write(delete.pos(), out);
	rowWriter.write(delete.row(), out);
	}

Core: Interface based DataFile reader and writer API #12298

Are you sure you want to change the base?

Core: Interface based DataFile reader and writer API #12298

Conversation

pvary commented Feb 17, 2025

Choose a reason for hiding this comment

pvary Feb 19, 2025 • 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

pvary Feb 19, 2025 • 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

liurenjie1024 left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pvary commented Feb 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rdblue commented Feb 22, 2025

pvary commented Feb 24, 2025

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

pvary Mar 18, 2025 • 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

snazy left a 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

pvary commented Mar 19, 2025

pvary Feb 19, 2025 •

edited

Loading

pvary Feb 19, 2025 •

edited

Loading

pvary commented Feb 21, 2025 •

edited

Loading

pvary Mar 18, 2025 •

edited

Loading