crepererum commented on issue #3777:
URL:
https://github.com/apache/arrow-datafusion/issues/3777#issuecomment-1311610241
Regarding all three crates: it seems weird to me that we mix state access
(i.e. listing and requesting objects) with modifiers. If you have a completely
static / DB-backed / remote catalog, it's unlikely that the modifiers make
sense. Instead, modifications (i.e. when/how/if sub-units are found) is a mere
implementation detail of the provider/list. In many cases, you may not be able
to modify the provider at all. So I would propose to maybe split the modifiers
from the actual provider traits? Like:
```rust
[async_trait]
pub trait CatalogList: Sync + Send {
fn as_any(&self) -> &dyn Any;
async fn catalog_names(&self) -> Result<Vec<String>>;
async fn catalog(&self, name: &str) -> Result<Option<Arc<dyn
CatalogProvider>>>;
}
[async_trait]
pub trait CatalogListWriter: CatalogList {
fn as_any(&self) -> &dyn Any;
async fn register_catalog(
&self,
name: String,
catalog: Arc<dyn CatalogProvider>
) -> Result<Option<Arc<dyn CatalogProvider>>>;
async fn deregister_catalog(&self, name: &str) -> Result<Option<Arc<dyn
CatalogProvider>>>;
}
```
Also since the providers now may perform IO, this is a good opportunity to
introduce error handling (e.g. make all methods return a `Result`).
--
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]
