feat(nodejs): feature parity [1/N] - remote table #1378
Conversation
universalmind303
requested review from
westonpace and
wjones127
and removed request for
westonpace
universalmind303
changed the title
|
ACTION NEEDED Lance follows the Conventional Commits specification for release automation. The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification. For details on the error please inspect the "PR Title Check" action. |
universalmind303
changed the title
nodejs/lancedb/remote/connection.ts
Outdated
| if (options?.mode) { | ||
| console.warn(`mode is not supported in remote connection, ignoring.`); | ||
| } |
There was a problem hiding this comment.
Could you describe what mode behaviour it is following here? It it going to error if the table already exists? Or overwrite the table?
There was a problem hiding this comment.
We can definitely make this a bit more informative. FWIW , I was copying the python message
I'd assume cloud behavior is to error on exists?
There was a problem hiding this comment.
Default behavior looks like it will error if the table already exists. We should make sure we have an integration test that validates this.
| // TODO: parse this into a valid arrow schema | ||
| return resp.schema; |
There was a problem hiding this comment.
Is this handled in one of the follow-up PRs?
There was a problem hiding this comment.
I don't have this handled yet.
The old vectorDB sdk was returning this AS IS and silently deviating from the type hints. Currently this mimics the same functionality, but I wanted to call out that this is not the correct behavior.
There was a problem hiding this comment.
Okay. This is fine for now.
…nnect({args})` (#1380)
depends on #1378
see proper diff here
universalmind303/lancedb@remote-table-node...universalmind303:lancedb:table-name
closes #1362