DerGut commented on code in PR #3000: URL: https://github.com/apache/iceberg-rust/pull/3000#discussion_r3842489032
########## crates/examples/src/datafusion_session_catalog.rs: ########## @@ -0,0 +1,303 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +//! Connects a session-aware Iceberg catalog to DataFusion. +//! +//! Run with: +//! +//! ```text +//! cargo run -p iceberg-examples --example datafusion-session-catalog +//! ``` +//! +//! The adapter at the bottom only makes the example self-contained. Applications +//! should pass their own `SessionCatalog` implementation to the provider. + +use std::collections::HashMap; +use std::sync::Arc; + +use async_trait::async_trait; +use datafusion::catalog::Session as DataFusionSession; +use datafusion::error::{DataFusionError, Result as DataFusionResult}; +use datafusion::prelude::{SessionConfig, SessionContext as DataFusionSessionContext}; +use iceberg::memory::{MEMORY_CATALOG_WAREHOUSE, MemoryCatalog, MemoryCatalogBuilder}; +use iceberg::spec::{NestedField, PrimitiveType, Schema, Type}; +use iceberg::table::Table; +use iceberg::{ + Catalog, CatalogBuilder, Namespace, NamespaceIdent, Result, SessionCatalog, + SessionContext as IcebergSessionContext, TableCommit, TableCreation, TableIdent, +}; +use iceberg_datafusion::{IcebergCatalogProvider, SessionContextResolver}; + +/// User metadata stored as an application-specific DataFusion extension. +#[derive(Debug)] +struct UserContext { + name: String, +} + +/// Maps the application's DataFusion user context to an Iceberg session. +#[derive(Debug)] +struct UserSessionContextResolver; + +impl SessionContextResolver for UserSessionContextResolver { + fn resolve(&self, session: &dyn DataFusionSession) -> DataFusionResult<IcebergSessionContext> { + let user = session + .config() + .get_extension::<UserContext>() + .ok_or_else(|| { + DataFusionError::Configuration( + "the DataFusion session has no UserContext extension".to_string(), + ) + })?; + + Ok(IcebergSessionContext::builder() + // Reusing the DataFusion session ID gives the catalog a stable key + // for session-scoped caches. + .session_id(session.session_id().to_string()) + .identity(user.name.to_string()) + .build()) + } +} + Review Comment: I have introduced an `IcebergOptions` struct with https://github.com/apache/iceberg-rust/pull/3000/changes/fc3995bb95d7f8e6249c5e5cbba712920559009b and replaced the `pub trait SessionContextResolver` with an internal function 🎉 This opened some questions about DataFusion's handling of sensitive configuration for me. Which trait implementations are actually required, given its string-based APIs? #### `ExtensionOptions` vs. `ConfigExtensions` My current understanding of the two configuration-related traits `ExtensionOptions` and `ConfigExtension` is that: [`ExtensionOptions`](https://docs.rs/datafusion-common/54.1.0/datafusion_common/config/trait.ExtensionOptions.html) (generated by the `extensions_options!` macro) powers string-based APIs to get and set pairs of key-values. [`ConfigExtensions`](https://docs.rs/datafusion-common/54.1.0/datafusion_common/config/trait.ConfigExtension.html) requires `ExtensionOptions` and registers options under a namespace (like `iceberg`). This enables setter APIs like: ```rust config.options_mut().set( "iceberg.credentials.token", "plaintext-secret", )?; ``` and configuration from SQL: ```sql SET iceberg.identity = 'alice'; ``` #### Match for `IcebergOptions` IMO both trait implementations are undesirable in the case of `IcebergOptions`. We certainly don't want a SQL query to set an identity or other authentication-related properties, so `ConfigExtensions` seems unneeded. I'm also skeptical of `ExtensionOptions` since it might allow unsafe accesses of secrets. DataFusion doesn't seem to require any of those traits, and by not implementing them, we'd force users to use programmatic APIs such as [`SessionConfig::with_extension`](https://docs.rs/datafusion/latest/datafusion/prelude/struct.SessionConfig.html#method.with_extension). #### Sensitive Options Precedents in DataFusion Some precedents exist for options structs that hold secrets in string format and implement all the above APIs. Notably [`AwsOptions`](https://github.com/apache/datafusion/blob/0d1f2ebe2cc97c91b736bc0a160b5b73cf40437a/datafusion-cli/src/object_storage.rs#L322) and [`GcpOptions`](https://github.com/apache/datafusion/blob/0d1f2ebe2cc97c91b736bc0a160b5b73cf40437a/datafusion-cli/src/object_storage.rs#L431). We could of course simply replicate that pattern but I feel like we can do better than that. -- 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]
