tanmayrauth commented on issue #1096: URL: https://github.com/apache/iceberg-go/issues/1096#issuecomment-4666863193
Actually I checked the Java reference ([HadoopCatalog.java](https://github.com/apache/iceberg/blob/main/core/src/main/java/org/apache/iceberg/hadoop/HadoopCatalog.java)), it points to a cleaner third option than either. Java never relies on mkdir's error semantics. createNamespace does an explicit existence check, then an idempotent recursive mkdirs: ``` if (isNamespace(nsPath)) throw new AlreadyExistsException(...); fs.mkdirs(nsPath); // recursive + idempotent; no error on exist/parent-missing ``` Two things follow: - The ErrExist/ErrNotExist mapping our Go code leans on is a Go-only embellishment — upstream doesn't enforce "parent must exist." - A namespace is only a directory — no marker file, no metadata (isNamespace = isDirectory && !isTableDir). That second point decides your option 2: with no marker to fall back on, a blob Mkdir that checks-but-creates-nothing leaves the namespace non-existent — List/Drop/Check read the prefix afterward and find nothing. Passes local tests, breaks only on the backend we can't easily test. Option 1 doesn't work either: CreateNamespace writes no file, so there's nothing to trigger the implicit mkdir, and WriteFile's fs.ErrNotExist conflates "parent missing" with "write failed" — exactly the misalignment you flagged. My preference: model it like the reference — Stat (exists → AlreadyExists) then create — and drop the dedicated Mkdir from the interface. Keeps the minimal surface (List + Stat + Read + Write + Remove(All) + Rename), no POSIX-only verb, identical local behavior. The error handling you liked about option 2 carries over cleanly: the ErrExist→AlreadyExists check becomes the Stat pre-check, and if you want to keep the "parent must exist" rule, do it with an explicit parent Stat rather than a Mkdir error. -- 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]
