mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-13 15:22:30 +00:00
jasonz-lanceandClaude Sonnet 5
40ff1d52a6
_open_pinned_table() reopened a private handle via _table_from_pickle_state(_table_to_pickle_state(self._table)) so checking it out to the block plan's pinned version would never mutate self._table. That held for local (on-disk) tables, whose pickle state is just reopen coordinates, but not for the other two table kinds: - RemoteTable: the pickle-state helpers special-case remote by returning the *same* object (correct for their original purpose -- cross-process pickling, where the unpickled copy necessarily lives in a different process -- but wrong for same-process reuse here). checkout() is a real in-place mutation on RemoteTable, so every 2-phase read pinned (and, since Cloud rejects writes through a version-pinned handle, effectively made read-only) the caller's own live table object. - memory://: the pickle state *is* the row data (to_arrow()), captured fresh on every _open_pinned_table() call instead of once at construction, so a write made after construction leaked into every later read -- the opposite of what a version pin is supposed to guarantee. A table already past version 1 also failed construction outright, since the rebuilt table is always a fresh version-1 table. Fix: deep-copy the RemoteTable instead (round-trips through its own __getstate__/__setstate__, which carries only reopen coordinates and clears the live connection handle, so the copy reconnects independently on first use). For local/memory tables, capture _pinned_table_state once at construction instead of recomputing it per call, and skip checkout() for memory tables -- a reopened memory table already is exactly the pinned snapshot by construction, and checking out a version number on it would fail since it only has one. Surfaced in the process: a reopened memory table's to_lance() always failed (pylance's raw lance.dataset() open can't resolve an isolated in-memory store), which forced every memory-table block read through the slower generic query builder with no error -- previously a gatekeeper-acknowledged non-blocking limitation, since it failed loudly rather than returning wrong data. _pinned_lance_dataset now recognizes a memory:// table up front (not only RemoteTable's NotImplementedError) and skips the native fast path for it, the same way it already does for RemoteTable, so memory-table block reads now also work correctly instead of merely failing safely. Added 3 regression tests: the caller's RemoteTable handle must stay unpinned after iterating a 2-phase dataset over a mocked remote table; a memory table's pin must survive a write made after construction; and constructing over a memory table already past version 1 must not raise. Full suite: 210 passed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Multimodal AI Lakehouse
How to Install ✦ Detailed Documentation ✦ Tutorials and Recipes ✦ Contributors
The ultimate multimodal data platform for AI/ML applications.
LanceDB is designed for fast, scalable, and production-ready vector search. It is built on top of the Lance columnar format. You can store, index, and search over petabytes of multimodal data and vectors with ease. LanceDB is a central location where developers can build, train and analyze their AI workloads.
Demo: Multimodal Search by Keyword, Vector or with SQL
Star LanceDB to get updates!
⭐ Click here ⭐ to see how fast we're growing!
Key Features:
- Fast Vector Search: Search billions of vectors in milliseconds with state-of-the-art indexing.
- Comprehensive Search: Support for vector similarity search, full-text search and SQL.
- Multimodal Support: Store, query and filter vectors, metadata and multimodal data (text, images, videos, point clouds, and more).
- Advanced Features: Zero-copy, automatic versioning, manage versions of your data without needing extra infrastructure. GPU support in building vector index.
Products:
- Open Source & Local: 100% open source, runs locally or in your cloud. No vendor lock-in.
- Cloud and Enterprise: Production-scale vector search with no servers to manage. Complete data sovereignty and security.
Ecosystem:
- Columnar Storage: Built on the Lance columnar format for efficient storage and analytics.
- Seamless Integration: Python, Node.js, Rust, and REST APIs for easy integration. Native Python and Javascript/Typescript support.
- Rich Ecosystem: Integrations with LangChain 🦜️🔗, LlamaIndex 🦙, Apache-Arrow, Pandas, Polars, DuckDB and more on the way.
How to Install:
Follow the Quickstart doc to set up LanceDB locally.
API & SDK: We also support Python, Typescript and Rust SDKs
| Interface | Documentation |
|---|---|
| Python SDK | https://lancedb.github.io/lancedb/python/python/ |
| Typescript SDK | https://lancedb.github.io/lancedb/js/globals/ |
| Rust SDK | https://docs.rs/lancedb/latest/lancedb/index.html |
| REST API | https://docs.lancedb.com/api-reference/rest |
Join Us and Contribute
We welcome contributions from everyone! Whether you're a developer, researcher, or just someone who wants to help out.
If you have any suggestions or feature requests, please feel free to open an issue on GitHub or discuss it on our Discord server.
Check out the GitHub Issues if you would like to work on the features that are planned for the future. If you have any suggestions or feature requests, please feel free to open an issue on GitHub.
Contributors
Stay in Touch With Us