Currently we report a checkpoint is finished only when `mxSafeFrame ==
mxFrame` in wal
it is useful to have finish callback to be triggered in case any work
moving frames was accomplished.
Currently we report a checkpoint is finished only when `mxSafeFrame ==
mxFrame` in wal
it is useful to have finish callback to be triggered in case any work
moving frames was accomplished.
bundled changes with new flag
This implementation is very much not ideal and should be reworked.
Its exposing the `Inne` type and `inner` parameter of `HranaStream`. I
can't think of a way to structure the code in a better way, but later we
could extend the protocol to include the changes made by the query as a
initial response, preventing having to hold a reference the the stream
all together.
Currently, we have a bug where each `push` request creates a new sync
session in the server. Each push request can send up to 128 frames.
However, if a transaction spans more than 128 frames, then it needs to
reuse the same sync session. Otherwise, the first push will succeed, but
the rest of the pushes will fail due to the write lock held by the
previous session.
This patch reuses the sync session. The way we do this is by using
batons. If the server sends a baton, then we pass it back. Reusing the
same baton ensures that we are using the same sync session.
Currently, we have a bug where each `push` request creates
a new sync session in the server. Each push request can send
up to 128 frames.
However, if a transaction spans more than 128 frames, then it
needs to reuse the same sync session. Otherwise, the first
push will succeed, but the rest of the pushes will fail due
to the write lock held by the previous session.
This patch reuses the sync session. The way we do this is
by using batons. If the server sends a baton, then we pass it
back. Reusing the same baton ensures that we are using
the same sync session.
libsql-ffi build on Windows has been intermittently broken for a while
due _build.rs_ calling `cp` which is not present on Windows.
Timeline:
- 2024-08-10: Issue #1657 was opened.
- 2024-11-14: #1791 was merged. First fix using `#[cfg(windows)]`.
- 2024-11-15: #1791 reverted in 9499c3c for breaking libsql-js on macOS.
- 2024-12-04: 9499c3c was reverted since #1791 was fine and did not
cause the macOS problem. Windows build works again.
- 2025-03-17: da54c1b breaks Windows build.
- 2025-03-21: 0.9.1 is released with broken Windows build.
- 2025-03-27: This commit fixes the bug introduced in da54c1b.
This commit fixes a bug introduced by da54c1b. `Command::status()?` was
propogating the error so the fallback, `fs::copy`, was never reached.
This is now fixed so libsql-ffi builds again on Windows.
Closes#1657
Right now, despite providing your own connector, the code
unconditionally calls its own connect function.
This has the side-effect of making sync incompatible with platforms
which do not have native certs ready.
This patch is a follow up on
https://github.com/tursodatabase/libsql/pull/2017 It changes the
heuristics for bootstrapping the DB.
One more change is, it also does bootstrap before any connection to the
local SQLite is created
Earlier, we bootstrapped whenever we noticed a change in the generation.
However, this patch changes this behaviour and does bootstrap only if
local files don't exist:
1. if no db file or the metadata file exists, then user is starting from
scratch
and we will do the sync
2. if the db file exists, but the metadata file does not exist (or other
way around),
then local db is in an incorrect state. we stop and return with an error
3. if the db file exists and the metadata file exists, then we don't
need to do the
sync
If we try to bootstrap the db after a connection is opened, then it is
incorrect, as it could create a local .db file and a successful sync
would replace this file
we use the following heuristic to determine if we need to sync the db file
1. if no db file or the metadata file exists, then user is starting from scratch
and we will do the sync
2. if the metadata file exists, but the db file does not exist,
then local db is in an incorrect state. we stop and return with an error
3. if the db file exists and the metadata file exists, then we don't need to do the
sync
libsql-ffi build on Windows has been intermittently broken for a while due _build.rs_ calling `cp` which is not present on Windows.
Timeline:
- 2024-08-10: Issue #1657 was opened.
- 2024-11-14: #1791 was merged. First fix using `#[cfg(windows)]`.
- 2024-11-15: #1791 reverted in 9499c3c for breaking libsql-js on macOS.
- 2024-12-04: 9499c3c was reverted since #1791 was fine and did not cause the macOS problem. Windows build works again.
- 2025-03-17: da54c1b breaks Windows build.
- 2025-03-21: 0.9.1 is released with broken Windows build.
- 2025-03-27: This commit fixes the bug introduced in da54c1b.
This commit fixes a bug introduced by da54c1b. `Command::status()?` was propogating the error so the fallback, `fs::copy`, was never reached.
This is now fixed so libsql-ffi builds again on Windows.
Closes#1657
Currently, the sync code pulls all the generations and frames one by
one. However, this is very inefficient, for databases with many
generations it could take hours.
This patch adds a optimisation that it pulls the latest generation by
calling `export` endpoint and boostraps the db file quickly.
My testing shows insane improvements. For a db with 30 generations, and
about 100 frames in each gen, it has brought down the initial sync from
1hr to 1 minute.
Fixes#1991
Currently, the sync code pulls all the generations and frames one by one.
However, this is very inefficient, for databases with many generations
it could take hours.
This patch adds a optimisation that it pulls the latest generation
by calling `export` endpoint and boostraps the db file quickly.
My testing shows insane improvements. For a db with 30 generations,
and about 100 frames in each gen, it has brought down the initial sync
from 1hr to 1 minute.
Fix#2004.
The gRPC code gets the `Status` information from the server to know if a
transaction was successful. Now, every time we try to run a statement,
the `is_autocommit` is run on the remote connection to know if we are in
a `State::Txn` or not.
After that, the code is basically a copy of
`crate::replication::connection::should_execute_local` with the addition
that when matching if the code should execute locally, the `state` is
set to the `predicted_end_state`. This step was skipped by the old
implementation because after a remote statement statement executed, the
end state came from the server as mentioned before.
`state` is mostly concerned to know if the server is in a transaction
and that we should keep sending remote queries until a `COMMIT` or
`ROLLBACK`. The match statement _could_ be refactored to reflect this
more clearly.
