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>
In #2845 we ported the lancedb integration in lance-namespace to
lancedb. But that is too specific to RestNamespace. We can improve the
user entry point so that we can put local mode and future version of the
Flight SQL-based LanceDB server all behind this single
`LanceDbNamespaceClientBuilder` API.
Also I renamed `namespace` to `namesapceClient` to avoid confusion with
the namespace path.
After the refactoring on both client and server side, we should have the
ability to fully use lance REST namespace to call into LanceDB cloud and
enterprise. We can avoid having a JNI implementation (which today does
not really do anything except for vending a connection object), and just
use lance-core's RestNamespace.
We will at this moment have a LanceDbRestNamespaceBuilder to allow users
to more easily build the RestNamespace to talk to LanceDB Cloud or
Enterprise endpoint.
In the future, we could extend this further to also support the local
mode through DirectoryNamespace. That will be a separated PR.
Daniel Rammer
Xuanwo
Jack Ye