2024-01-01 14:58:21 -05:00
|
|
|
// Copyright 2018-2024 the Deno authors. All rights reserved. MIT license.
|
2022-10-01 06:15:56 -04:00
|
|
|
|
|
|
|
use deno_core::error::AnyError;
|
|
|
|
use deno_core::serde_json;
|
|
|
|
use deno_runtime::deno_webstorage::rusqlite::params;
|
|
|
|
|
2024-03-21 14:35:51 -04:00
|
|
|
use crate::node::CliCjsAnalysis;
|
|
|
|
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
use super::cache_db::CacheDB;
|
|
|
|
use super::cache_db::CacheDBConfiguration;
|
|
|
|
use super::cache_db::CacheFailure;
|
2024-05-29 14:38:18 -04:00
|
|
|
use super::CacheDBHash;
|
2022-10-01 06:15:56 -04:00
|
|
|
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
pub static NODE_ANALYSIS_CACHE_DB: CacheDBConfiguration =
|
|
|
|
CacheDBConfiguration {
|
2024-05-29 14:38:18 -04:00
|
|
|
table_initializer: concat!(
|
|
|
|
"CREATE TABLE IF NOT EXISTS cjsanalysiscache (",
|
|
|
|
"specifier TEXT PRIMARY KEY,",
|
|
|
|
"source_hash INTEGER NOT NULL,",
|
|
|
|
"data TEXT NOT NULL",
|
|
|
|
");"
|
|
|
|
),
|
2023-07-19 04:30:04 -04:00
|
|
|
on_version_change: "DELETE FROM cjsanalysiscache;",
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
preheat_queries: &[],
|
|
|
|
on_failure: CacheFailure::InMemory,
|
|
|
|
};
|
2022-10-01 06:15:56 -04:00
|
|
|
|
2023-02-03 14:15:16 -05:00
|
|
|
#[derive(Clone)]
|
2022-10-01 06:15:56 -04:00
|
|
|
pub struct NodeAnalysisCache {
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
inner: NodeAnalysisCacheInner,
|
2022-10-01 06:15:56 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
impl NodeAnalysisCache {
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
pub fn new(db: CacheDB) -> Self {
|
2022-10-01 06:15:56 -04:00
|
|
|
Self {
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
inner: NodeAnalysisCacheInner::new(db),
|
2022-10-01 06:15:56 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
fn ensure_ok<T: Default>(res: Result<T, AnyError>) -> T {
|
|
|
|
match res {
|
|
|
|
Ok(x) => x,
|
|
|
|
Err(err) => {
|
|
|
|
// TODO(mmastrac): This behavior was inherited from before the refactoring but it probably makes sense to move it into the cache
|
|
|
|
// at some point.
|
|
|
|
// should never error here, but if it ever does don't fail
|
|
|
|
if cfg!(debug_assertions) {
|
|
|
|
panic!("Error using esm analysis: {err:#}");
|
|
|
|
} else {
|
|
|
|
log::debug!("Error using esm analysis: {:#}", err);
|
|
|
|
}
|
|
|
|
T::default()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-10-01 06:15:56 -04:00
|
|
|
pub fn get_cjs_analysis(
|
|
|
|
&self,
|
|
|
|
specifier: &str,
|
2024-05-29 14:38:18 -04:00
|
|
|
expected_source_hash: CacheDBHash,
|
2024-03-21 14:35:51 -04:00
|
|
|
) -> Option<CliCjsAnalysis> {
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
Self::ensure_ok(
|
|
|
|
self.inner.get_cjs_analysis(specifier, expected_source_hash),
|
|
|
|
)
|
2022-10-01 06:15:56 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
pub fn set_cjs_analysis(
|
|
|
|
&self,
|
|
|
|
specifier: &str,
|
2024-05-29 14:38:18 -04:00
|
|
|
source_hash: CacheDBHash,
|
2024-03-21 14:35:51 -04:00
|
|
|
cjs_analysis: &CliCjsAnalysis,
|
2022-10-01 06:15:56 -04:00
|
|
|
) {
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
Self::ensure_ok(self.inner.set_cjs_analysis(
|
|
|
|
specifier,
|
|
|
|
source_hash,
|
|
|
|
cjs_analysis,
|
|
|
|
));
|
2022-10-01 06:15:56 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
#[derive(Clone)]
|
2022-10-01 06:15:56 -04:00
|
|
|
struct NodeAnalysisCacheInner {
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
conn: CacheDB,
|
2022-10-01 06:15:56 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
impl NodeAnalysisCacheInner {
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
pub fn new(conn: CacheDB) -> Self {
|
|
|
|
Self { conn }
|
2022-10-01 06:15:56 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
pub fn get_cjs_analysis(
|
|
|
|
&self,
|
|
|
|
specifier: &str,
|
2024-05-29 14:38:18 -04:00
|
|
|
expected_source_hash: CacheDBHash,
|
2024-03-21 14:35:51 -04:00
|
|
|
) -> Result<Option<CliCjsAnalysis>, AnyError> {
|
2022-10-01 06:15:56 -04:00
|
|
|
let query = "
|
|
|
|
SELECT
|
|
|
|
data
|
|
|
|
FROM
|
|
|
|
cjsanalysiscache
|
|
|
|
WHERE
|
|
|
|
specifier=?1
|
|
|
|
AND source_hash=?2
|
|
|
|
LIMIT 1";
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
let res = self.conn.query_row(
|
|
|
|
query,
|
2024-05-29 14:38:18 -04:00
|
|
|
params![specifier, expected_source_hash],
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
|row| {
|
|
|
|
let analysis_info: String = row.get(0)?;
|
|
|
|
Ok(serde_json::from_str(&analysis_info)?)
|
|
|
|
},
|
|
|
|
)?;
|
|
|
|
Ok(res)
|
2022-10-01 06:15:56 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
pub fn set_cjs_analysis(
|
|
|
|
&self,
|
|
|
|
specifier: &str,
|
2024-05-29 14:38:18 -04:00
|
|
|
source_hash: CacheDBHash,
|
2024-03-21 14:35:51 -04:00
|
|
|
cjs_analysis: &CliCjsAnalysis,
|
2022-10-01 06:15:56 -04:00
|
|
|
) -> Result<(), AnyError> {
|
|
|
|
let sql = "
|
|
|
|
INSERT OR REPLACE INTO
|
|
|
|
cjsanalysiscache (specifier, source_hash, data)
|
|
|
|
VALUES
|
|
|
|
(?1, ?2, ?3)";
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
self.conn.execute(
|
|
|
|
sql,
|
|
|
|
params![
|
|
|
|
specifier,
|
2024-05-29 14:38:18 -04:00
|
|
|
source_hash,
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
&serde_json::to_string(&cjs_analysis)?,
|
|
|
|
],
|
|
|
|
)?;
|
2022-10-01 06:15:56 -04:00
|
|
|
Ok(())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
mod test {
|
|
|
|
use super::*;
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
pub fn node_analysis_cache_general_use() {
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
let conn = CacheDB::in_memory(&NODE_ANALYSIS_CACHE_DB, "1.0.0");
|
|
|
|
let cache = NodeAnalysisCacheInner::new(conn);
|
2022-10-01 06:15:56 -04:00
|
|
|
|
2024-05-29 14:38:18 -04:00
|
|
|
assert!(cache
|
|
|
|
.get_cjs_analysis("file.js", CacheDBHash::new(2))
|
|
|
|
.unwrap()
|
|
|
|
.is_none());
|
2024-03-21 14:35:51 -04:00
|
|
|
let cjs_analysis = CliCjsAnalysis::Cjs {
|
2022-10-01 06:15:56 -04:00
|
|
|
exports: vec!["export1".to_string()],
|
|
|
|
reexports: vec!["re-export1".to_string()],
|
|
|
|
};
|
|
|
|
cache
|
2024-05-29 14:38:18 -04:00
|
|
|
.set_cjs_analysis("file.js", CacheDBHash::new(2), &cjs_analysis)
|
|
|
|
.unwrap();
|
|
|
|
assert!(cache
|
|
|
|
.get_cjs_analysis("file.js", CacheDBHash::new(3))
|
|
|
|
.unwrap()
|
|
|
|
.is_none()); // different hash
|
|
|
|
let actual_cjs_analysis = cache
|
|
|
|
.get_cjs_analysis("file.js", CacheDBHash::new(2))
|
|
|
|
.unwrap()
|
2022-10-01 06:15:56 -04:00
|
|
|
.unwrap();
|
2024-03-21 14:35:51 -04:00
|
|
|
assert_eq!(actual_cjs_analysis, cjs_analysis);
|
2022-10-01 06:15:56 -04:00
|
|
|
|
|
|
|
// adding when already exists should not cause issue
|
|
|
|
cache
|
2024-05-29 14:38:18 -04:00
|
|
|
.set_cjs_analysis("file.js", CacheDBHash::new(2), &cjs_analysis)
|
2022-10-01 06:15:56 -04:00
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
// recreating with same cli version should still have it
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
let conn = cache.conn.recreate_with_version("1.0.0");
|
|
|
|
let cache = NodeAnalysisCacheInner::new(conn);
|
2024-05-29 14:38:18 -04:00
|
|
|
let actual_analysis = cache
|
|
|
|
.get_cjs_analysis("file.js", CacheDBHash::new(2))
|
|
|
|
.unwrap()
|
|
|
|
.unwrap();
|
2024-03-21 14:35:51 -04:00
|
|
|
assert_eq!(actual_analysis, cjs_analysis);
|
2022-10-01 06:15:56 -04:00
|
|
|
|
|
|
|
// now changing the cli version should clear it
|
feat(core): initialize SQLite off-main-thread (#18401)
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
2023-03-27 18:01:52 -04:00
|
|
|
let conn = cache.conn.recreate_with_version("2.0.0");
|
|
|
|
let cache = NodeAnalysisCacheInner::new(conn);
|
2024-05-29 14:38:18 -04:00
|
|
|
assert!(cache
|
|
|
|
.get_cjs_analysis("file.js", CacheDBHash::new(2))
|
|
|
|
.unwrap()
|
|
|
|
.is_none());
|
2022-10-01 06:15:56 -04:00
|
|
|
}
|
|
|
|
}
|