feat: page_token / limit to native table_names function. Use async table_names function from sync table_names function (#1059)

The synchronous table_names function in python lancedb relies on arrow's
filesystem which behaves slightly differently than object_store. As a
result, the function would not work properly in GCS.

However, the async table_names function uses object_store directly and
thus is accurate. In most cases we can fallback to using the async
table_names function and so this PR does so. The one case we cannot is
if the user is already in an async context (we can't start a new async
event loop). Soon, we can just redirect those users to use the async API
instead of the sync API and so that case will eventually go away. For
now, we fallback to the old behavior.
This commit is contained in:
Weston Pace
2024-03-05 08:38:18 -08:00
committed by GitHub
parent 47dbb988bf
commit 9148cd6d47
21 changed files with 250 additions and 83 deletions

View File

@@ -69,11 +69,20 @@ impl Connection {
self.inner.take();
}
pub fn table_names(self_: PyRef<'_, Self>) -> PyResult<&PyAny> {
pub fn table_names(
self_: PyRef<'_, Self>,
start_after: Option<String>,
limit: Option<u32>,
) -> PyResult<&PyAny> {
let inner = self_.get_inner()?.clone();
future_into_py(self_.py(), async move {
inner.table_names().await.infer_error()
})
let mut op = inner.table_names();
if let Some(start_after) = start_after {
op = op.start_after(start_after);
}
if let Some(limit) = limit {
op = op.limit(limit);
}
future_into_py(self_.py(), async move { op.execute().await.infer_error() })
}
pub fn create_table<'a>(