superdb-mcp 1.3.1 → 1.3.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.js CHANGED
@@ -17,7 +17,7 @@ const __dirname = dirname(__filename);
17
17
  const docsDir = join(__dirname, '../docs');
18
18
  const server = new Server({
19
19
  name: 'superdb-mcp',
20
- version: '1.3.1',
20
+ version: '1.3.3',
21
21
  }, {
22
22
  capabilities: {
23
23
  tools: {},
@@ -8,6 +8,10 @@ web: "https://chrismo.github.io/superkit/_build/tutorials/chess-tiebreaks/"
8
8
 
9
9
  # Chess Tiebreaks
10
10
 
11
+ SuperDB isn't limited to JSON — it can ingest and transform plain text just as
12
+ easily. This tutorial demonstrates parsing raw text input using `grok` patterns,
13
+ reshaping records, and aggregating results to answer a real question.
14
+
11
15
  PGN (Portable Game Notation) is a plain text format for recording chess games.
12
16
  Each game has metadata in bracketed lines like `[White "LastName, FirstName"]`
13
17
  followed by the moves. Here we'll parse a tournament's PGN file to find players
@@ -21,8 +21,8 @@ web: "https://chrismo.github.io/superkit/_build/tutorials/joins/"
21
21
 
22
22
  Left Join (Left Only + Inner Joins — where clause required to eliminate inner joins)
23
23
 
24
- Note: In 0.1.0, `select *` now includes columns from both sides. The right table's
25
- columns get a `_1` suffix to avoid name collisions, and unmatched values are
24
+ `select *` includes columns from both sides. The right table's columns get a
25
+ `_1` suffix to avoid name collisions, and unmatched values are
26
26
  `error("missing")`.
27
27
  ```mdtest-command
28
28
  super -s -c "select * from za.sup as za
@@ -92,7 +92,7 @@ super -s -c '
92
92
  {id:4,date:"2025-02-28",foo:9}
93
93
  ```
94
94
 
95
- `super` also supports SQL syntax, and these subqueries work:
95
+ `super` also supports SQL syntax, and these subqueries work[^1]:
96
96
 
97
97
  ```mdtest-command
98
98
  super -s -c '
@@ -220,6 +220,9 @@ super -s -c '
220
220
  {id:4,date:"2025-02-28",score:9,name:"Sprocket"}
221
221
  ```
222
222
 
223
+ [^1]: SQL subqueries that reference files re-read the file for each subquery,
224
+ which increases CPU usage and wall time compared to the piped approach.
225
+
223
226
  # as of versions
224
227
 
225
228
  ```mdtest-command
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "superdb-mcp",
3
- "version": "1.3.1",
3
+ "version": "1.3.3",
4
4
  "description": "MCP server for SuperDB - execute SuperSQL queries, version detection, and embedded documentation",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",
@@ -1,32 +0,0 @@
1
- ---
2
- name: moar-subqueries
3
- description: "Additional subquery patterns including fork and full sub-selects."
4
- superdb_version: "0.2.0"
5
- last_updated: "2026-02-15"
6
- web: "https://chrismo.github.io/superkit/_build/tutorials/moar_subqueries/"
7
- ---
8
-
9
- # Moar Subqueries
10
-
11
- ## Fork
12
-
13
- One hassle to this approach is the limit of 2 forks. Nesting forks works, but
14
- makes constructing this query a bit more difficult.
15
-
16
- ## Full Sub-Selects
17
-
18
- As of 20250815 build, this is much, much slower. I'm guessing it's doing a full
19
- reload of the data file each time.
20
-
21
- ```
22
- select
23
- (select count(*)
24
- from './moar_subqueries.sup'
25
- where win is not null) as total_games,
26
- ...
27
- ```
28
-
29
- ## All Other SQL-Syntax Subqueries
30
-
31
- They all take about the same amount of wall-time, but CPU usage is much higher
32
- due to re-reading the file each time.
@@ -1,31 +0,0 @@
1
- ---
2
- name: super-db-update
3
- description: "Workarounds for updating data in a SuperDB lake."
4
- superdb_version: "0.2.0"
5
- last_updated: "2026-02-15"
6
- web: "https://chrismo.github.io/superkit/_build/tutorials/super_db_update/"
7
- ---
8
-
9
- # Updating Data in a Lake
10
-
11
- There are plans to eventually support this, captured in this [GitHub Issue
12
- #4024](https://github.com/brimdata/super/issues/4024). But for now, we'll have
13
- to fudge it.
14
-
15
- All we can do for now are separate `delete` and `load` actions. It's safer to do
16
- a load-then-delete, in case the delete fails, we'll at least have duplicated
17
- data, vs. no data at all in the case of failure during a delete-then-load.
18
-
19
- Since we have unstructured data, we can attempt to track the ...
20
-
21
- load: {id:4,foo:1,ts:time('2025-02-18T01:00:00')}
22
- load: {id:4,foo:2,ts:time('2025-02-18T02:00:00')}
23
- delete: -where 'id==4 and ts < 2025-02-18T02:00:00'
24
-
25
- if it's typed data
26
-
27
- delete: -where 'is(<foo>) ...'
28
-
29
- if we need to double-check duplicate data:
30
-
31
- 'count() by is(<foo>)'