Daniel Rammer
a651b67c76
Four of the eight LSM methods are remote-only in the core: `impl BaseTable for NativeTable` implements only set/unset/get_lsm_write_spec and close_lsm_writers, while flush_lsm, compact_lsm and get_lsm_stats fall through to trait defaults returning NotSupported. That is why Node had bound the four that work locally and stopped, and why the remaining four had no binding-level coverage anywhere. Node: add napi bindings for flush_lsm, compact_lsm, checkpoint_lsm and get_lsm_stats, with typed LsmStats/BucketStats/GenerationStats/ MemtableStats objects mirroring the existing LsmWriteSpec object in the same file. Tests assert each binding reaches the core and surfaces NotSupported locally; behavior against a real endpoint stays covered by the mocked-endpoint tests in rust/lancedb/src/remote/table.rs. Python: LsmWriteSpec was importable only from the private lancedb._lancedb -- it appeared in table.py solely under `if TYPE_CHECKING:`. Export it as lancedb.LsmWriteSpec, add it to __all__, and list it in the API reference, which had no mention of it and so rendered it nowhere. Java: add the LSM routes to lancedb-core. Java reaches LanceDB purely over REST through the generated namespace client, and these routes are not in the Lance Namespace spec, so they are issued through a small dedicated client. LsmWriteSpec is deliberately not org.lance.memwal. InitializeMemWalParams: that type defaults to maintaining no indexes where a spec here defaults to maintaining every index, and it cannot express the null that asks the server to resolve the set. checkpointLsm is ported from rust/lancedb/src/table/checkpoint.rs with its constants and status semantics intact -- 429/503 retried in place, 421 restarting from flush. Note: `mvnw spotless:apply` cannot run on JDK 21 (google-java-format 1.7, pinned in java/pom.xml, predates JDK 16's compiler API change). This is pre-existing and reproduces on a pristine main checkout; the Java sources here were formatted by hand to the checkstyle rules. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
LanceDB Documentation
LanceDB docs are available at docs.lancedb.com.
The SDK docs are built and deployed automatically by Github Actions
whenever a commit is pushed to the main branch. So it is possible for the docs to show
unreleased features.
Building the docs
Setup
- Install LanceDB Python. See setup in Python contributing guide.
Run
make developto install the Python package. - Install documentation dependencies. From LanceDB repo root:
pip install -r docs/requirements.txt
Preview the docs
cd docs
mkdocs serve
If you want to just generate the HTML files:
PYTHONPATH=. mkdocs build -f docs/mkdocs.yml
If successful, you should see a docs/site directory that you can verify locally.
Adding examples
To make sure examples are correct, we put examples in test files so they can be run as part of our test suites.
You can see the tests are at:
- Python:
python/python/tests/docs - Typescript:
nodejs/examples/
Checking python examples
cd python
pytest -vv python/tests/docs
Checking typescript examples
The @lancedb/lancedb package must be built before running the tests:
pushd nodejs
npm ci
npm run build
popd
Then you can run the examples by going to the nodejs/examples directory and
running the tests like a normal npm package:
pushd nodejs/examples
npm ci
npm test
popd
API documentation
Python
The Python API documentation is organized based on the file docs/src/python/python.md.
We manually add entries there so we can control the organization of the reference page.
However, this means any new types must be manually added to the file. No additional
steps are needed to generate the API documentation.
Typescript
The typescript API documentation is generated from the typescript source code using typedoc.
When new APIs are added, you must manually re-run the typedoc command to update the API documentation. The new files should be checked into the repository.
pushd nodejs
npm run docs
popd