amogh-jahagirdar commented on code in PR #9247:
URL: https://github.com/apache/iceberg/pull/9247#discussion_r1427181875
##########
core/src/main/java/org/apache/iceberg/view/BaseView.java:
##########
@@ -103,4 +105,27 @@ public UpdateLocation updateLocation() {
public UUID uuid() {
return UUID.fromString(ops.current().uuid());
}
+
+ /**
+ * This implementation of sqlFor will resolve what is considered the
"closest" dialect. If an
+ * exact match is found, then that is returned. Otherwise, the last
representation would be
+ * returned. If no SQL representation is found, null is returned.
+ */
+ @Override
+ public ViewRepresentation sqlFor(String dialect) {
+ Preconditions.checkArgument(dialect != null, "Invalid dialect: null");
+ ViewVersion current = operations().current().currentVersion();
+ ViewRepresentation closest = null;
+ for (ViewRepresentation viewRepresentation : current.representations()) {
+ if (Objects.equals(viewRepresentation.type(),
ViewRepresentation.Type.SQL)) {
+ SQLViewRepresentation sqlViewRepresentation = (SQLViewRepresentation)
viewRepresentation;
+ if (sqlViewRepresentation.dialect().equalsIgnoreCase(dialect)) {
+ return sqlViewRepresentation;
+ }
+
+ closest = sqlViewRepresentation;
Review Comment:
I don't really have a preference as long as it's consistent (always first or
always last or well defined based on some other heuristic).
What's the main benefit you see for using the first? Is it just that it's
easier to see in the metadata?
For context, I chose the last just because the implementation is cleaner
there (just need a single loop over the representations and tracking the
closest is just a matter of updating a reference until either an exact match is
found or the loop completes and we return the closest which would be null in
case there's no SQL representation).
--
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: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
