nastra commented on code in PR #7880:
URL: https://github.com/apache/iceberg/pull/7880#discussion_r1250671566
##########
api/src/main/java/org/apache/iceberg/view/ViewBuilder.java:
##########
@@ -111,6 +111,16 @@ public interface ViewBuilder {
*/
ViewBuilder withProperty(String key, String value);
+ /**
+ * Add a view representation
+ *
+ * @param representation The view representation to add
+ * @return this for method chaining
+ */
+ default ViewBuilder withRepresentation(ViewRepresentation representation) {
Review Comment:
We had a short discussion with @danielcweeks / @rdblue / @Fokko last week
on the `ViewBuilder` API and I just wanted to give below an overview of what
options we have when
1) creating a view with one (or more) view representations
2) adding additional representations, updating an existing representation
and deleting representations
We currently don't know yet how the final Builder would look like, so the
purpose here is to facilitate a discussion and to define the API and its
behavior.
It's worth mentioning that most things have been already implemented in this
PR and the PR will be updated once we define the final API and its behavior.
## 1) ViewBuilder granularity
### Option A: Existing ViewBuilder using fine-grained Dialect/Query
definitions
It's only possible to define a single representation that is specific to
SQL. While this might be ok - because the Spark SQL for defining a View would
always only map to defining a single view representation - the main drawback of
this API
is that it is fine-grained and very specific to a SQL representation.
Once new representations are introduced, the ViewBuilder methods would have
to be adjusted to account for the new type of representations.
```
// define a view for a single dialect
View view =
catalog()
.buildView(identifier)
.withSchema(SCHEMA)
.withDialect("spark")
.withQuery("select * from ns.tbl")
.create();
```
### Option B: ViewBuilder using ViewRepresentation API in its Builder methods
The advantage of this approach is that the `ViewBuilder` API wouldn't have
to be updated when new representations are introduced, because
`.withRepresentation()` takes a `ViewRepresentation`.
Additionally, this allows to define more than a single representation when
the view is created.
```
ViewRepresentation spark =
ImmutableSQLViewRepresentation.builder()
.dialect("spark")
.sql("select * from ns.tbl")
.build();
ViewRepresentation trino =
ImmutableSQLViewRepresentation.builder()
.sql("select * from ns.tbl")
.dialect("trino")
.build();
// define a view for trino + spark
View view =
catalog()
.buildView(identifier)
.withSchema(SCHEMA)
.withRepresentation(spark)
.withRepresentation(trino)
.create();
```
## 2) Adding/Updating/Removing Representations
By introducing a `UpdateViewRepresentation` API it is possible to
add/remove/updated view representations.
### Adding
After the view is created for spark, an additional representation can be
added via:
```
// add trino dialect
SQLViewRepresentation trino =
ImmutableSQLViewRepresentation.builder()
.sql("select * from ns.tbl")
.dialect("trino")
.build();
view.updateRepresentation().add(trino).commit();
```
### Removing
This adds a representation for trino and removes an existing one for spark:
```
// add trino dialect
SQLViewRepresentation trino =
ImmutableSQLViewRepresentation.builder()
.sql("select * from ns.tbl")
.dialect("trino")
.build();
view.updateRepresentation().add(trino).remove("spark").commit();
```
### Updating
Using a combination of `.remove()` and `add()` it's possible to mimic an
update
```
// update trino dialect
SQLViewRepresentation trino =
ImmutableSQLViewRepresentation.builder()
.sql("select * from ns.tbl")
.dialect("trino")
.build();
view.updateRepresentation().remove(trino.dialect()).add(trino).commit();
```
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]