C-Loftus commented on issue #1096:
URL: https://github.com/apache/iceberg-go/issues/1096#issuecomment-4661054102
@tanmayrauth That makes sense. Quick question, I am working on condensing
HadoopCatalogFS and wanted to align on your preference for how to deal with the
mismatch between `mkdir` in a local filesystem and the fact object stores don't
have this same concept.
Do you prefer:
1. The `mkdir` operation being moved to within the `WriteFile` function in
the localfs struct and removing the `MkdirIO` interface entirely?
- I initially was going to remove `MkdirIO` and do this option, but I am
worried that adding a mkdir operation to the `localfs` struct deviates from the
interface by adding implicit behavior.
- In this implementation, to check for a directory nothing existing we
would need to use a `WalkDir` call which would be necessary for a blob store,
but unnecessary for a localfs.
```go
if errors.Is(err, fs.ErrExist) {
return fmt.Errorf("%w: %s",
catalog.ErrNamespaceAlreadyExists, strings.Join(ns, "."))
}
if errors.Is(err, fs.ErrNotExist) {
return fmt.Errorf("%w: parent namespace does not exist
for %s",
catalog.ErrNoSuchNamespace, strings.Join(ns,
"."))
}
```
- The error handling would also misalign a bit, requiring us to check for
`fs.ErrNotExist` on `WriteFile` calls due to the fact it would call `mkdir` for
the filesystem implementation.
2. The other option would be that `Mkdir` in the blob store
implementation, would be nothing but a check that the base path of the full
path exists. We would keep `MkdirIO` interface for explicitness.
- While it is one extra function in the interface, I think that this
may make the behavior more explicit. This allows us to keep the same error
handling logic for filesystem functionality and makes the behavior explicit.
- This would keep similar semantics around error handling and allow
us to check `fs.ErrNotExist` in a similar way
Let me know what you think, thanks!
--
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]
