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
|
@@ -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
|
package/docs/tutorials/joins.md
CHANGED
|
@@ -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
|
-
|
|
25
|
-
|
|
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,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>)'
|