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
This PR implements the strftime scalar function. It uses underneath the
hood chrono's strftime function and the already existent modifier logic.
The caveat of using chrono's strftime implementation is that it supports
some additional syntax that is not supported in sqlite, such as
precision modifiers (%.3f). If this is a deal breaker for this function
to be implemented at the moment, I will then write a strftime
implementation from scratch.
Closes#778
