jerryshao commented on code in PR #4292:
URL: https://github.com/apache/gravitino/pull/4292#discussion_r1698323808
##########
catalogs/catalog-lakehouse-paimon/src/main/java/org/apache/gravitino/catalog/lakehouse/paimon/GravitinoPaimonTable.java:
##########
@@ -51,7 +64,25 @@ protected TableOperations newOps() {
* @return The converted Paimon table.
*/
public Schema toPaimonTableSchema() {
- Schema.Builder builder =
Schema.newBuilder().comment(comment).options(properties);
+ Schema.Builder builder = Schema.newBuilder().comment(comment);
+ if (properties == null) {
+ properties = Maps.newHashMap();
+ }
+ if (partitioning == null) {
+ partitioning = EMPTY_PARTITIONING;
+ }
+
+ Map<String, String> normalizedProperties = new HashMap<>(properties);
+ normalizedProperties.remove(PRIMARY_KEY_IDENTIFIER);
Review Comment:
After discuss with @FANNG1 privately, I think it is suitable to use
`PRIMARY_INDEX` than a property to define a key here. Though the behavior of
Paimon is slightly different from RDBMS, it is still some sorts of primary key,
right? In Gravitino, we only semantically unify them, not in behavior, each
implementation can have it's own explanation, like what we defined for types,
transforms, distributions, we only define them semantically, but we don't
restrict the behavior, each implementation may be different. So this also
applies to here.
Still, we can extend the current PRIMARY_INDEX definition to better support
Paimon, WDYT? @caican00
--
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]
