This patch adds some libSQL vector extension functions such as
`vector()` and `vector_distance_cos()`, which can be used for exact
nearest neighbor search as follows:
```
limbo> SELECT embedding, vector_distance_cos(embedding, '[9, 9, 9]')
...> FROM movies ORDER BY vector_distance_cos(embedding, '[9, 9, 9]');
[4, 5, 6]|0.013072490692138672
[1, 2, 3]|0.07417994737625122
```
Now:
```sql
limbo> create table t (a,b,c); insert into t (a,b,c) values ("hello", 234, 432);
thread 'main' panicked at core/translate/expr.rs:1621:29:
internal error: entered unreachable code: Id should be resolved to a Column before translation
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
After fix:
```sql
limbo> create table t (a,b,c); insert into t (a,b,c) values ("hello", 234, 432);
× Parse error: no such column: "hello" - should this be a string literal in single-quotes?
limbo>
```
Closes#800
Reviewed-by: Diego Reis (@diegoreis42)
Reviewed-by: Preston Thorpe (@PThorpe92)
Closes#801
## Purpose of this PR
- Implement `close()` method for `LimboStatement`(+`JDBC4Statement`) and
`LimboResultSet`(+ `JDBC4ResultSet`)
## Changes
- Add `consumeAll` method in `LimboResultSet`
- Implement `close()` methods
- Because `JDBC4Statement` has longer lifecycle in compared to
`LimboStatement`, we manage different `close` fields(`LimboStatement` is
created when first `execute` method is called on `JDBC4Statemenet`)
## Reference
- [Issue](https://github.com/tursodatabase/limbo/issues/615)
Closes#799
## Purpose of thie PR
- Implement `close()` method for `LimboConnection` and `JDBC4Connection`
## Changes
- Instead of closing the database when closing connections, close the
connection instead
## References
- https://github.com/tursodatabase/limbo/issues/615Closes#797
This PR introduces the ability to build and link with an extension
library, enabling features like `uuid` to not have to be shipped as
independent libraries and loaded at runtime.
To build and link with an extension, you simply add it as a dependency
with the `static` feature, and call register_extension_static. in this
case, we feature flag that with `uuid`
```rust
#[cfg(feature = "uuid")]
pub fn register_uuid(&self) -> Result<(), String> {
let ext_api = Box::new(self.build_limbo_ext());
if unsafe { !limbo_uuid::register_extension_static(&ext_api).is_ok() } {
return Err("Failed to register uuid extension".to_string());
}
Ok(())
}
```
So fortunately wasm targets are no longer excluded from extensions, only
loading them at runtime for now
Closes#737
Current micro-optimizations:
- store single data structure for cursors in programstate, not one for
every cursor type
- use vec for cursors instead of btreemap
- use knowledge of cursor amount to pre-allocate cursor vec capacity
- don't use resize in ::new() and ::reset(), instead populate directly
and reset by iterating over each elem (somehow this is faster)
- use bitfield for ended_coroutine instead of hashmap
Closes#782
The first rule of writing fast programs: don't use dynamic memory
allocation!
Brings `SELECT 1` micro-benchmark back to 70 ns, which is a bit closer
to what we had before.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#781
The first rule of writing fast programs: don't use dynamic memory
allocation!
Brings back some performance for the `SELECT 1` micro-benchmark,
although we're still not where we need to be.
The current status of the PR is halfway. The new framing of simulation
runner where `setup_simulation` is separated from `run_simulation`
allows for injecting custom plans easily. The PR is currently missing
the functionality to update the `SimulatorEnv` ad hoc from the plan, as
the environment tables were typically created during the planning phase.
The next steps will be to implement a function `fn
mk_env(InteractionPlan, SimulatorEnv) -> SimulatorEnv`, add `--load`
flag to the CLI for loading a serialized plan file, making a
corresponding environment and running the simulation.
We can optionally combine this with a `--save` option, in which we keep
a seed-vault as part of limbo simulator, corresponding each seed with
its generated plan and save the time to regenerate existing seeds by
just loading them into memory. I am curious to hear thoughts on this?
Would the maintainers be open to adding such a seed-vault? Do you think
the saved time would be worth the complexity of the approach?
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#720
This WIP driver uses the [purego](github.com/ebitengine/purego) library,
that supports cross platform `Dlopen`/`Dlsym` and not a whole lot else.
I really didn't want to use CGO, have very little experience with WASM
and I heard nothing but good things about this library. It's very easy
to use and stable especially when you consider the use case here of 3
functions.
NOTE: The WIP state that this PR is in right at this moment, is not able
to run these simple queries. This screengrab was taken from a couple
days ago when I wrote up a quick demo to load the library, call a simple
query and had it println! the result to make sure everything was working
properly.
I am opening this so kind of like the Java bindings, I can incrementally
work on this. I didn't want to submit a massive PR, try to keep them at
~1k lines max. The state of what's in this PR is highly subject and
likely to change.
I will update when they are at a working state where they can be tested
out and make sure they work across platforms.
Closes#776
