Currently we have a Record, which is a dumb vector of cloned values.
This is incredibly bad for performance as we do not want to clone
objects unless needed. Therefore, let's start by introducing this type
so that any record that has already been serialized will be returned
from btree in the format of a simple payload with reference to payload.
Closes#1176
- Use `CheckpointResult::default()` instead of `CheckpointResult::new()`
- Correct WAL frame header salt and checksum handling
- Ensure frame ID is 1-based and adjust frame offset calculation
- Add `Default` implementation for `CheckpointResult`
- Use random values for WAL header salts
Currently we have a Record, which is a dumb vector of cloned values.
This is incredibly bad for performance as we do not want to clone
objects unless needed. Therefore, let's start by introducing this type
so that any record that has already been serialized will be returned
from btree in the format of a simple payload with reference to payload.
SQLite uses a similar approach for operations where up to 4 JSON objects
are accessed multiple times in a single query.
`SELECT json_extact(a, 'some_path'), json_remove(a, 'some_path')
json_set(a, 'some_path', 'some_value') from t;`
Closes#1163
It is a Minimal Valuable Close (MVC) to #494 and #1146 , so probably
there are some corner cases to handle, if so, just point it out and I'll
be happy to fix it :)
Closes#1148
Ensure the Arc<RefCell<Buffer>> in UringFile::pwrite remains alive until
the io_uring write completes by referencing it in the completion callback.
This prevents WAL file corruption where the correct buffer data was
overwritten with stale memory (e.g., 00 18 27 xx instead of 37 7f 06 82).
Validation:
- Tested with limbo -v io_uring and WAL operations.
- Verified with xxd and wal-browser.
Signed-off-by: Daniel Boll <danielboll.academico@gmail.com>
I keep having 3+ PR's in at the same time and always deal with crazy
conflicts because everything in the `ext` library is together in one
file.
This PR moves each category of extension into its own file, and
separates the `vfs` functionality in Core into the `ext/dynamic` module,
so that it can be more easily separated from wasm (or non feature =
"fs") targets to prevent build issues.
The only semantic changes made in this PR is the feature gating of vfs,
the rest is simply organizing and cleaning up imports.
Was unsure if `vfs` should be a feature on the `core` side too, or to
just enable it with the `fs` feature which seemed reasonable, as that
was already the current behavior. But let me know if we want it entirely
behind it's own feature.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#1124
