transformations - updates by sh-rp · Pull Request #2718 · dlt-hub/dlt

sh-rp · 2025-06-05T11:49:41Z

Description

This PR includes the following changes:

Convert the readable dataset to handle sqlglot expressions where possible without intermediary steps where sql strings are generated and re-parsed.
Changes the transformation function to expect generators also for sql queries and relations
Add a configuration option to force materialization (this is very useful for testing, but also may come in handy when doing data quality checks that require extraction later)
Uses regular relations as dataitem object, adds new interface to mark an object that may compute its schema_hints
Moves handling of hints for sql transformations into the extractor.
Adds support for working with unbound ibis tables as well as native support for unbound ibis expressions for the call method of the dataset and transformations
Adds support for adding resource hints to pyarrow items that can be consumed by the ArrowExtractor
Removes ibis relation and consolidates dataset and relation implementations into one class each
Updates protocols for relation and dataset and makes these the publicly facing interface for these classes.
Updated docs

Open questions:

The whole handling of hints needs to be reviewed and probably improved. I am unwrapping and wrapping dataitems in the transformations now and this feels more like a workaround at this point. Also I am not sure if the place where the hints get merged (user supplied hints vs hints from the relation) is right, I am not 100% sure what I am doing there.

netlify · 2025-06-05T11:49:46Z

✅ Deploy Preview for dlt-hub-docs canceled.

Name	Link
🔨 Latest commit	`bd4cfd7`
🔍 Latest deploy log	https://app.netlify.com/projects/dlt-hub-docs/deploys/6870ef4fb8a68a0008447f74

sh-rp · 2025-06-05T11:52:03Z

dlt/transformations/transformation.py

+        select_query = transformation_result.query()

-        # TODO: why? don't we prevent empty column schemas above?
        all_columns = {**computed_columns, **(columns or {})}


I have added a test for columns merging, and the columns yielded from here overwrite all incoming columns definitions from the decorator, which I think generally makes sense in dlt, but not for the transformations. I would maybe keep this topic open for now until we decide how this should work exactly.

w8: you are overwriting computed_columns with columns which come from the decorator. so how are they not overwritten at the end?

I am not sure what you are asking. My goal would be, that if the user sets a column hin on the transformation decorator, this should overwrite whatever is discovered during lineage. At least I think it should, but I can also just remove this line and users will have to deal with this in some other way if they need to change precision or something like that.

sh-rp · 2025-06-05T11:53:02Z

tests/transformations/test_lineage.py

 QUERY_KNOWN_TABLE_STAR_SELECT = "SELECT * FROM table_1"
 QUERY_UNKNOWN_TABLE_STAR_SELECT = "SELECT * FROM table_unknown"
 QUERY_ANONYMOUS_SELECT = "SELECT LEN(col_varchar) FROM table_1"
-QUERY_GIBBERISH = "%&/ GIBBERISH"


this can not happen anymore, as non parseable sql strings are already caught in the dataset.

sh-rp · 2025-06-05T11:53:55Z

tests/transformations/test_transformations.py

+    def inventory_original(dataset: SupportsReadableDataset[Any]) -> Any:
+        return dataset["inventory"]
+
+    @dlt.transformation(columns={"price": {"precision": 20, "scale": 2}})


I think this is the correct behavior, we should allow to set the precision for an existing column here. Or would you rather do this in the function body? I am not sure.

sh-rp · 2025-06-05T15:04:32Z

docs/website/docs/general-usage/transformations/index.md

+Will be translated to
+
+```sql
+INSERT INTO 


this is the actually generated insert statement. I realized we were not quoting identifiers, so I added this. We are doing 2 subqueries here now, one stemming from the normalization in the extract and one from @anuunchin normalizer work. We can probably still optimize here?

sh-rp · 2025-06-05T15:26:23Z

tests/normalize/test_model_item_normalizer.py

        assert (
            normalized_query
-            == 'SELECT _dlt_subquery."a" AS a, _dlt_subquery."b" AS b, UUID() AS _dlt_id FROM'
+            == 'SELECT _dlt_subquery."a" AS "a", _dlt_subquery."b" AS "b", UUID() AS "_dlt_id" FROM'


the model item normalizer will now always use quoted identifiers on the outer queries, regardless wether the inner select has quoted identifiers. Since all queries arriving here now go through query normalization in the dataset where quotes are applied, this should be fine acutally.

sh-rp · 2025-06-06T11:21:05Z

dlt/destinations/dataset/ibis_relation.py

+    def _query(self) -> sge.Query:
+        from dlt.helpers.ibis import duckdb_compiler
+
+        select_query = duckdb_compiler.to_sqlglot(self._ibis_object)


For converting an ibis expression into sqlglot, you always need a compiler which is destination dependent. I think the compiler will fail if you use function that are known not to exist on a specific destination, and certain materializations will also occur in this step. If you have an expression that counts rows, the alias for the result will be created here, which will be CountStar(*) for duckdb, but which is not a valid identifier for bigquery for example (see comment in query normalizer)

sh-rp · 2025-06-06T11:23:38Z

dlt/destinations/dataset/utils.py

                    if node.db != expanded_path[0]:
                        node.set("catalog", sqlglot.to_identifier(expanded_path[0], quoted=False))
+        if isinstance(node, sge.Alias):
+            node.set("alias", naming.normalize_identifier(node.alias))


Here I make sure aliases that are created by the user or automatically by ibis in the compile step above adhere to the naming convention of the current destination. The alternative would be to use a different compiler for every destination. Normalizing the alias in the ModelNormalizer step is too late, since this code is also used for just accessing the data. Without this change, def test_row_counts will fail for bigquery because an alias with invalid symbols remains in the query. All other destinations seem to accept this.

I have reverted this change and am now using the bigquery compiler only for bigquery destinations. Maybe we should be using the correct compiler for each destination type, but it seems duckdb works for all. I am not sure about this one.

rudolfix · 2025-06-12T11:32:29Z

dlt/destinations/dataset/ibis_relation.py

+        # NOTE: We can use the duckdb compiler for all dialects except for bigquery
+        # as bigquery is more strict about identifier naming and will not accept
+        # identifiers generated by the duckdb compiler for anonymous columns
+        destination_dialect = self._dataset.sql_client.capabilities.sqlglot_dialect


I'll keep the old notes:
# NOTE: ibis is optimized for reading a real schema from db and pushing back optimized sql
# - it quotes all identifiers, there's no option to get unqoted query
# - it converts full lists of column names back into star
# - it optimizes the query inside, adds meaningless aliases to all tables etc.

for example: I bet that BigQuery problem is quotation problem where " are not accepted

rudolfix · 2025-06-12T11:32:52Z

dlt/destinations/dataset/relation.py

+                "Must be an SQL SELECT statement."
+            )
+
+        return query.sql(dialect=self._dataset.sql_client.capabilities.sqlglot_dialect)


why provided_dialect is not used here?

dlt/destinations/dataset/relation.py

rudolfix · 2025-06-15T20:21:07Z

dlt/destinations/dataset/utils.py

    sqlglot_schema: SQLGlotSchema,
    qualified_query: sge.Query,
    sql_client: SqlClientBase[Any],
+    naming: NamingConvention,


not needed anymore. and I think it should not be needed here

rudolfix · 2025-06-15T20:27:12Z

dlt/transformations/transformation.py

+        select_query = transformation_result.query()

-        # TODO: why? don't we prevent empty column schemas above?
        all_columns = {**computed_columns, **(columns or {})}


w8: you are overwriting computed_columns with columns which come from the decorator. so how are they not overwritten at the end?

rudolfix · 2025-06-15T20:35:03Z

dlt/transformations/transformation.py

-                    + "Please run with strict lineage or provide data_type hints "
-                    + f"for following columns: {unknown_column_types}",
-                )
            yield dlt.mark.with_hints(


this is something I wrote in the old PR: could we place all_column in the SqlModel? or better: could we place a relation in it? then:

user is able to use dlt.mark on the model (ie. their own custom hints or table name)

all_columns = {**computed_columns, **(columns or {})} is not needed. columns will be applied by compute_table_schema in DltResource

you can use relation/computed_columns in SqlModel to apply to the resource in extractor. Look how we call this method

root_table_schema = resource.compute_table_schema(items, meta)

and

def compute_table_schema(self, item: TDataItem = None, meta: Any = None) -> TTableSchema: """Computes the table schema based on hints and column definitions passed during resource creation. `item` parameter is used to resolve table hints based on data. `meta` parameter is taken from Pipe and may further specify table name if variant is to be used """

so SqlModel will be passed there and you can use it to extract computed hints.

Or you can implement _compute_schema on ModelExtractor for fully custom logic

I kind of did that now, but I also have to unwrap and rewrap the dataitem in the transform function and I am not fully convinced that the way I did it is the right way.. Also I don't think it works for materialized queries...

sh-rp · 2025-06-26T12:57:45Z

dlt/transformations/transformation.py

+from dlt.extract.pipe_iterator import DataItemWithMeta
+
+
+class MaterializableSqlModel(SqlModel, WithComputableHints):


Note: find better name, or merge this with relation.

sh-rp · 2025-06-26T12:58:42Z

dlt/transformations/transformation.py

+            relation = unwrapped_item
+        # we see if the string is a valid sql query, if so we need a dataset
+        elif isinstance(unwrapped_item, str):
+            try:


this will allow a malformed sql query to be interpreted as string, possibly not what we want here, maybe single strings should always strictly be interpreted as sql query and fail this transformation, otherwise the user will have very strange results.

sh-rp · 2025-06-26T13:00:15Z

dlt/transformations/transformation.py

-            for chunk in datasets[0](select_query).iter_arrow(chunk_size=config.buffer_max_items):
-                yield dlt.mark.with_hints(chunk, hints=make_hints(columns=all_columns))
+            for chunk in relation.iter_arrow(chunk_size=config.buffer_max_items):
+                yield dlt.mark.with_hints(chunk, hints=sql_model.compute_hints())


here we discard the hints coming from the outside, for the sqlmodel they are merged during extract, but since we have pure arrow tables here, we can't do it. We had this idea of putting our schema into the user data area of the arrow table. I have not looked at this yet, but should we do it?

…t of unneeded transpiling clean up make_transformation function tests still pending

…oad stage

rudolfix · 2025-07-01T21:46:41Z

I will review tests later

sh-rp · 2025-07-02T08:00:43Z

I will review tests later

There are a bunch of relevant tests in tests/load/pipeline/test_model_item_format.py which can probably be moved to transformation tests.

-> this allows to have multiple relations with different schemas in the relation, so this is allowed now too

sh-rp · 2025-07-02T09:51:23Z

OK! this is pretty minor stuff now. I have one question for execution order. We execute models randomly right? so if I access data from output dataset (ie. dlt.current.pipeline.dataset()) I may get partially modified destination data.

maybe we should have a mode that we always use staging dataset? it seems we just need append strategy

I would add a note in the docs, I think it's quite unlikely that users would use tables from the output dataset as input in the same load.

rudolfix

LGTM! just a few more questions

tests/transformations/test_transformations.py

rudolfix · 2025-07-02T14:09:40Z

tests/transformations/test_transformations.py

+    fruit_p.run(fruitshop_source())
+
+    @dlt.transformation()
+    def multiple_transformations(dataset: Dataset) -> Any:


would be cool to enumerate resource without pipeline and also to have a mixed easy and eager transformations yielded

Resources are enumerated and schema access is tested in test_extract_without_source_name_or_pipeline and test_materializable_sql_model and test_enumerate_and_access_relation.

For the mixed type function a small fix in the normalizer was needed that prevented mixed loader_file_type tables in general

rudolfix · 2025-07-02T14:10:24Z

tests/transformations/test_transformations.py

+            ["id", "customer_id", "inventory_id", "quantity", "name"]
+        ]
+
+    model = list(materializable_sql_model(fruit_p.dataset()))[0]


do we have a specific test for resource iteration?

I'm not sure what this means, this is tested in the line above, no?

* Min max, filter with expr_or_string * Fix in min max test * Overload fix and docs * Test read interfaces partially uses default relation max

…metrized types and don't supply hints if none are present in dlt schema

sh-rp · 2025-07-07T07:01:49Z

dlt/extract/extractors.py

            if table_name in self._filtered_tables:
                continue
            # allow to cache dynamic table hints if only table name is dynamic
-            if table_name not in self._table_contracts or resource._table_has_other_dynamic_hints:


@rudolfix I had to revert his change that you made, because yielding multiple transformations with different schemas would not work without it. Relevant test is: def test_multiple_transformations_in_function. Maybe you should review this once again.

right! but this prevents caching of the computed dynamic table hints which is 99% of cases we handle. my take:
convert _table_has_other_dynamic_hints into has_other_dynamic_hints which for transformation resources is always True and for others it falls back to the current behavior

# Conflicts: # dlt/common/destination/capabilities.py

zilto · 2025-07-10T01:02:20Z

input_data

I believe this shouldn't be here?

zilto · 2025-07-10T01:15:36Z

dlt/common/destination/dataset.py

-        raise NotImplementedError("`fetchone()` method is not supported for this relation")
+
+
+class Relation(DataAccess):


AFAIU, DataAccess and Relation are implemented as abstract base classes (abc.ABC) rather than duck-typing (Protocol). The class Relation inheriting DataAccess protocol should implement the methods directly (otherwise, make Relation the protocol).

For instance, the type inspection from the IDE complains that all methods don't return anything while they indicate they do.

What's the practical use case here? I thought IbisRelation was removed to have a single Dataset and Relation implementation. This has the benefit of shedding this abstract machinery

We have interfaces (protocols or abstract classes) in common and implementations in the other parts. This enables us to have these interfaces as return types in places where the implementation is not known or can not be imported due to circular dependencies

Also wrt to the protocol vs abc: Ideally the Relation would also be a Protocol, the problem is, that I am checking variables for types in the transformations to see what the transformations are yielding, and you can't check for protocols (or you can with runtime_checkable decorator but apparently that is very slow). I also don't see any problems in my IDE, maybe we are using different linters? The CI passes.

This enables us to have these interfaces as return types in places where the implementation is not known or can not be imported due to circular dependencies

For this purpose, we should simply use

from __future__ import annotations from typing import TYPE_CHECKING if TYPE_CHECKING: # import from other modules

We should gradually introduce levels of abstraction. If we have a single dlt.Dataset and dlt.Relation, the additional layers make reading and editing the code harder IMO. For instance, I still struggle with the many layers of proxying and wrapping on Relation.df(), which could be written in a very straightforward manner

rudolfix · 2025-07-10T10:31:36Z

dlt/common/data_writers/writers.py

-
-            normalized_query = parsed_query.sql(dialect=dialect)
-            self._f.write("dialect: " + (dialect or "") + "\n" + normalized_query + "\n")
+            dialect = item.query_dialect() or (self._caps.sqlglot_dialect if self._caps else None)


my question was: can item.query_dialect() NOT return a dialect in current impl? so we can remove expression after "or"

rudolfix · 2025-07-10T10:34:50Z

dlt/transformations/transformation.py

    def __init__(self, *args: Any, **kwds: Any) -> None:
        super().__init__(*args, **kwds)

+    def compute_table_schema(self, item: TDataItem = None, meta: Any = None) -> TTableSchema:


this background why we do the schema caching and when

rudolfix · 2025-07-10T10:37:34Z

dlt/destinations/dataset/relation.py

+        return self._columns_schema
+
+    @columns_schema.setter
+    def columns_schema(self, new_value: TTableSchemaColumns) -> None:


ping! can we remove it?

* rename flag for executing raw queries to "execute_raw_query" * return sge queries from the internal _query method which removes a lot of unneeded transpiling clean up make_transformation function tests still pending * adds some tests to readable dataset and a test for column hint merging * allows any dialect when writing queries and fixes tests * update docs and set correct quoting to queries in normalization and load stage * fixes normalizer tests * fix limit on mssql normalize aliases in normalization step * add missing quote to alias * revert identifier normalization step in normalizer_query and use bigquery compiler for bigquery destinations * post rebase fix * smallish pr fixes * add materializable sqlmodel and handle hints in extractor * add and test always_materialize setting * add test for sql transformation type * convert transformation functions to need yield instead of return * migrate tests and docs snippets to yield in transformations * add simple test for materializable model * use correct compiler for converting ibis into sqlglot for each dialect fixes on transformation test * add first simple version of using unbound ibis tables in transformations * skip ibis test on python 3.9 * fix query building in new relation * return a "real" relation from a transformation * add ibis option when getting table from dataset natively support unbound ibis tables in transformations and when getting relations from dataset * update model item format tests to use relation * * remove one unneeded test (same thing is already tested in transformations) * fix wei conversion in linneage * adds support for adding resource hints to pyarrow items * switch most read access tests to default dataset * update datasets and transformations docs pages * separate ibis and default dbapi datasets and fix typing * update transformation tests and small typing fixes for updated datasets * fix default dataset type * fix wei sqlglot conversion * add sqlglot dialect type and some cleanup * fix dataset snippets * fix sqlglot schema test * removes ibis relation and dataset consolidates relation and dataset baseclasses with implementations updates interfaces/protocols fro relation and dataset and makes those the publicly available interface with "Relation" and "Dataset" remove query method from relation interface * fix one doc snippet * rename dataset and relation interfaces * fix relation ship between cursor and relation, remove function wiring hack in favor of explicit forwarding for better typing * clean up readablerelation (no actual code changes) * fix str test to assume pretty sql (which it is now) fix one transformation snippet * small changes from review comments: * query method on dataset * typing update of table method * rename query method to "to_sql" on relation * clean up transform function a bit (could maybe be even better= reject non-sql strings in transformation to not shadow errors * add support for "non-generator" transformations * move hints computation into resource class * smallish PR fixes * add support for dynamic hints in transformations -> this allows to have multiple relations with different schemas in the relation, so this is allowed now too * fixes dynamic table caching * Enhances ReadableDBAPIRelation: min/max, filter with expression (#2833) * Min max, filter with expr_or_string * Fix in min max test * Overload fix and docs * Test read interfaces partially uses default relation max * prevent sqglot schema from adding default hints info, only allow parametrized types and don't supply hints if none are present in dlt schema * make multi schema transformations work again * move model item format tests to transformations folder * re-order interface tests and fix playground dataset access * PR review test updated * update dataset and transformation pages * update transformations tests to new fruitshop * Last PR fixes * update columns_schema property --------- Co-authored-by: Marcin Rudolf <rudolfix@rudolfix.org> Co-authored-by: anuunchin <88698977+anuunchin@users.noreply.github.com>

sh-rp commented Jun 5, 2025

View reviewed changes

sh-rp commented Jun 6, 2025

View reviewed changes

sh-rp force-pushed the feat/transformations-more-decoupling branch from 211cbfc to 1f5a787 Compare June 6, 2025 12:44

sh-rp marked this pull request as ready for review June 11, 2025 07:21

sh-rp requested a review from rudolfix June 11, 2025 07:21

sh-rp force-pushed the feat/transformations-more-decoupling branch from 848233e to 28b7361 Compare June 11, 2025 13:50

rudolfix assigned sh-rp Jun 15, 2025

rudolfix requested changes Jun 15, 2025

View reviewed changes

sh-rp mentioned this pull request Jun 18, 2025

Transformation release ToDos #2776

Closed

11 tasks

sh-rp force-pushed the feat/transformations-more-decoupling branch 4 times, most recently from 6ae764d to 3584402 Compare June 25, 2025 15:07

sh-rp changed the title ~~transformations - more decoupling~~ transformations - new versions Jun 26, 2025

sh-rp force-pushed the feat/transformations-more-decoupling branch from cc89745 to 941dae0 Compare June 26, 2025 12:42

sh-rp commented Jun 26, 2025

View reviewed changes

sh-rp force-pushed the feat/transformations-more-decoupling branch from 36e2e96 to 93c97e2 Compare June 26, 2025 15:04

sh-rp added 5 commits June 26, 2025 17:19

rename flag for executing raw queries to "execute_raw_query"

825610c

return sge queries from the internal _query method which removes a lo…

c149269

…t of unneeded transpiling clean up make_transformation function tests still pending

adds some tests to readable dataset and a test for column hint merging

70116a6

allows any dialect when writing queries and fixes tests

51a91ca

update docs and set correct quoting to queries in normalization and l…

20405f1

…oad stage

sh-rp added 2 commits July 2, 2025 10:46

smallish PR fixes

41e1239

add support for dynamic hints in transformations

57e09fd

-> this allows to have multiple relations with different schemas in the relation, so this is allowed now too

fixes dynamic table caching

0eccfdd

rudolfix reviewed Jul 2, 2025

View reviewed changes

anuunchin and others added 6 commits July 4, 2025 15:07

Enhances ReadableDBAPIRelation: min/max, filter with expression (#2833)

a141170

* Min max, filter with expr_or_string * Fix in min max test * Overload fix and docs * Test read interfaces partially uses default relation max

Merge branch 'devel' into feat/transformations-more-decoupling

15b4a43

prevent sqglot schema from adding default hints info, only allow para…

3b46e8a

…metrized types and don't supply hints if none are present in dlt schema

make multi schema transformations work again

5b906ad

move model item format tests to transformations folder

44ae438

re-order interface tests and fix playground dataset access

089f5ec

sh-rp force-pushed the feat/transformations-more-decoupling branch from d04e962 to 089f5ec Compare July 5, 2025 10:40

sh-rp commented Jul 7, 2025

View reviewed changes

PR review test updated

b06d715

sh-rp force-pushed the feat/transformations-more-decoupling branch from 9e72cf7 to 19822bc Compare July 7, 2025 10:03

update dataset and transformation pages

c5f9b33

sh-rp force-pushed the feat/transformations-more-decoupling branch from 19822bc to c5f9b33 Compare July 7, 2025 10:29

sh-rp added 2 commits July 9, 2025 10:27

Merge branch 'devel' into feat/transformations-more-decoupling

b6577fd

# Conflicts: # dlt/common/destination/capabilities.py

update transformations tests to new fruitshop

63dfa5f

zilto mentioned this pull request Jul 9, 2025

exp: @dlt.transformation ergonomics #2757

Closed

zilto reviewed Jul 10, 2025

View reviewed changes

rudolfix requested changes Jul 10, 2025

View reviewed changes

sh-rp added 2 commits July 11, 2025 11:11

Last PR fixes

83372df

update columns_schema property

bd4cfd7

sh-rp merged commit befe9ce into devel Jul 11, 2025
59 checks passed

zilto mentioned this pull request Jul 13, 2025

fix: typing for updated datasets and relations Protocols #2870

Merged

rudolfix deleted the feat/transformations-more-decoupling branch January 20, 2026 10:04

		from dlt.extract.pipe_iterator import DataItemWithMeta


		class MaterializableSqlModel(SqlModel, WithComputableHints):

		raise NotImplementedError("`fetchone()` method is not supported for this relation")


		class Relation(DataAccess):

Comments

Conversation

sh-rp commented Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

netlify bot commented Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for dlt-hub-docs canceled.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sh-rp Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rudolfix commented Jul 1, 2025

Uh oh!

sh-rp commented Jul 2, 2025

Uh oh!

sh-rp commented Jul 2, 2025

Uh oh!

rudolfix left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zilto Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

sh-rp commented Jun 5, 2025 •

edited

Loading

netlify bot commented Jun 5, 2025 •

edited

Loading

sh-rp Jun 25, 2025 •

edited

Loading

zilto Jul 10, 2025 •

edited

Loading

sh-rp Jul 11, 2025 •

edited

Loading