You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 23, 2025. It is now read-only.
* Implement memory session storage
* Implement database session storage
* Implement redis session storage
* Run redis for GitHub tests
* Rename filesystem to file (system)
* Use memory session store for test default
Copy file name to clipboardExpand all lines: CHANGELOG.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -47,7 +47,7 @@ Version 5 contains many infrastructure and API changes, as well as migrations th
47
47
48
48
This release finishes the migration from an embedded JSON database to an ORM and SQLite (used by default). For new instances of SQLPad, the following alternative backend databases may be used: SQL Server, MySQL, MariaDB, or PostgreSQL via `SQLPAD_BACKEND_DB_URI`.
49
49
50
-
Providing a value for `SQLPAD_DB_PATH`/`dbPath` is still required, as the filesystem is still used for sessions and storage of query results. This requirement will be removed in a later 5.x release.
50
+
Providing a value for `SQLPAD_DB_PATH`/`dbPath` is still required, as the file system is still used for sessions and storage of query results. This requirement will be removed in a later 5.x release.
51
51
52
52
Migrations will be run on SQLPad start up. To disable this behavior, set `SQLPAD_DB_AUTOMIGRATE` to `false`. Migrations may be run manually via `node server.js --config path/to/file.ext --migrate`. When using `--migrate` the process will exit after applying migrations.
53
53
@@ -205,12 +205,12 @@ Special thanks to @eladeyal-intel, @bruth, @yorek, @dengc367, @murphyke, and @Wi
205
205
- Add GitHub Release builds via build pipeline (#550)
206
206
- Add `dbInMemory` setting (#553)
207
207
208
-
`dbInMemory` will run the embedded SQLPad db in memory without logging to disk. Enabling this does not remove the need for `dbPath` at this time, as filesystem access is still required for result caches and express session support. (`dbPath` to become optional in future release)
208
+
`dbInMemory` will run the embedded SQLPad db in memory without logging to disk. Enabling this does not remove the need for `dbPath` at this time, as file system access is still required for result caches and express session support. (`dbPath` to become optional in future release)
209
209
210
210
### Fixes
211
211
212
212
- Fix TypeError: Do not know how to serialize a BigInt (#522)
Copy file name to clipboardExpand all lines: docs/api-batches.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ Prior to v5, queries were run in SQLPad with an HTTP `POST`, with the query resu
10
10
11
11
While nice and simple, it has some downsides:
12
12
13
-
- long queries require long HTTP timeout configurations (not ideal, requires additional configuration to load balancers, proxy, etc)
13
+
- long queries require long HTTP timeout configurations (not ideal, requires additional configuration to load balancers, proxy, etc.)
14
14
- An execution with multiple statements/queries would require all queries to finish before results are sent back. Results would have to be in single response (might be too big)
15
15
16
16
As of v5 new restful APIs have replaced the existing query-result API.
@@ -21,9 +21,9 @@ These newly created objects are returned as soon as they are created, each conta
21
21
22
22
Immediately following creation, the batch is executed, each statement sequentially, under the same connection if the database driver supports it. On error, further statements in the batch are stopped, and the statement and batch in question is marked as status `error`.
23
23
24
-
On success, the batch and statement are marked with status `finished`. Query results are written to the filesystem as a JSON file under the `results` directory inside the directory specified by the `dbPath` configuration variabled.
24
+
On success, the batch and statement are marked with status `finished`. Query results are written to the file system as a JSON file under the `results` directory inside the directory specified by the `dbPath` configuration variable.
25
25
26
-
These results on the filesystem are kept according to the `queryHistoryRetentionTimeInDays` setting, which defaults to 30 days.
26
+
These results on the file system are kept according to the `queryHistoryRetentionTimeInDays` setting, which defaults to 30 days.
Copy file name to clipboardExpand all lines: docs/getting-started.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@
4
4
5
5
There are 2 options to run SQLPad: Install [Node.js](https://nodejs.org/) and [build and run SQLPad from the git repository](https://github.com/rickbergfalk/sqlpad/blob/master/DEVELOPER-GUIDE.md), or use the [docker images on Docker Hub](https://hub.docker.com/r/sqlpad/sqlpad/).
6
6
7
-
SQLPad does not require any additional servers other than its own self. By default it uses SQLite and the filesystem for storing queries, query results, and web sessions. SQLite may be replaced with an external database using the `SQLPAD_BACKEND_DB_URI` environment variable as of v5.
7
+
SQLPad does not require any additional servers other than its own self. By default it uses SQLite and the file system for storing queries, query results, and web sessions. SQLite may be replaced with an external database using the `SQLPAD_BACKEND_DB_URI` environment variable as of v5.
8
8
9
9
The `SQLPAD_DB_PATH` must still be provided however, as it is used for sessions and query result storage. This requirement will be removed in a later 5.x release.
0 commit comments