The kit was pinned to website 963d734 -- MODULE_API 1.6.0, the Teams cutover --
and the platform is on 1.9.0. Three registrations and two calls arrived in
between, and a reader building against this book would have found no mention of
any of them: a module can now declare what its game can announce, and never who
is told.
Moving `ci/core-ref.json` is the mechanism for exactly this. The pin is now
66bb3b9a (website `main`, the engagement cutover) and `template/module.json`
declares `^1.9.0`.
What chapter 2 gained, under "Telling core something happened":
* a TRIGGER is a payload contract, not a notification stream -- the two share
one id namespace and are constantly confused;
* `ceiling` is required, has no default, and is a CONTAINMENT tree rather than
a size ladder (a `staff` ceiling does not permit `owner`);
* an AUDIENCE resolver returns user ids and nothing else, resolves to NOBODY
on failure, and takes CONSTANT params -- the constraint worth knowing before
you design around it;
* templates re-ensure per seedVersion, rule groups are offered ONCE per group
key, so a rule appended to an existing group reaches fresh installs only;
* `ctx.events.emit` binds the owner and is fire-and-forget; `ctx.inbox.push`
is the direct write, for when there is nothing for an operator to decide.
The template builds all of it: one trigger, one audience over the clan roster it
already had, one seeded body and one seeded rule group, and an emitter in
`boot.js` that fires on the TRANSITION rather than on the poll. Seven new tests,
including the audience that resolves to nobody when its query throws.
Three claims were wrong and are corrected here rather than shipped:
* core validates `subjectKey` against the declared variables and refuses the
module; the draft taught a cooldown keyed on `undefined`, which the check
exists to prevent and a reader will never see.
* `emit` throws OUTSIDE production and only drops-and-logs inside it. Teaching
the second half alone leaves a developer meeting a throw the book says
cannot happen.
* the seeded body itself was malformed -- heading `level: 2` where the block
registry takes 'h2', and no block ids at all.
The third is the one worth keeping: `registerEngagementSeeds` checks that
`blocks` is a non-empty array and stops, so that body would have registered,
seeded, and failed the first time an operator opened it. Found by running the
template's `register()` through core's real registry at the pinned ref -- which
CI does not do, and cannot: the template job checks the version and runs the
template against fakes. A fake accepts what core refuses. The gap is now named
in the chapter, beside the code, and in the pin's own comment, and the rule that
bit has a test that fails on it.
Also: `checkLinks` skipped `.core/`. Bumping this pin means cloning core into
that directory first, and the walk then reported nine broken links in someone
else's README. CI never saw it -- the clone happens in the `template` job and
the check runs in `prose` -- so it was a failure only a person could meet.
Co-Authored-By: Claude <noreply@anthropic.com>
107 lines
4.2 KiB
JavaScript
107 lines
4.2 KiB
JavaScript
// ── SQL for the clan tables ───────────────────────────────────────────────
|
|
//
|
|
// The same `.db.js` / `.model.js` split as `model/worldStatus/`, for the same
|
|
// reason: the file with the queries in it has no branching to test, and the file
|
|
// with the branching in it has no database to stand up.
|
|
//
|
|
// Everything here reads this module's OWN tables. **Nothing in a module ever
|
|
// reads or writes `teams`, `team_members`, `team_forum_*` or any other core
|
|
// table** — core owns the Team, this module owns the clan, and the whole of the
|
|
// traffic between them is the provider next door answering three questions
|
|
// (MODULE_API.md §2.6's prefix rule, and §2.7).
|
|
|
|
const core = require('../../core')
|
|
|
|
const CLANS = 'examplegame_clans'
|
|
const MEMBERS = 'examplegame_clan_members'
|
|
|
|
/** Every clan the game has told us about. */
|
|
async function listClans() {
|
|
return core.query(
|
|
`SELECT external_id AS externalId, name, abbr, member_count AS memberCount
|
|
FROM ${CLANS}
|
|
ORDER BY name`,
|
|
)
|
|
}
|
|
|
|
/** One clan, or `undefined`. */
|
|
async function findClan(externalId) {
|
|
const rows = await core.query(
|
|
`SELECT external_id AS externalId, name, abbr, member_count AS memberCount
|
|
FROM ${CLANS}
|
|
WHERE external_id = ?`,
|
|
[externalId],
|
|
)
|
|
return rows[0]
|
|
}
|
|
|
|
/**
|
|
* One clan's roster.
|
|
*
|
|
* Ordered so that a page rendering it directly does not have to sort: leaders
|
|
* first, then by name. Ordering in SQL rather than in the model is a judgement
|
|
* call and this is the case for it — the database is doing it on an index, and
|
|
* the alternative is every caller remembering to.
|
|
*/
|
|
async function listMembers(clanId) {
|
|
return core.query(
|
|
`SELECT member_key AS memberKey, display_name AS displayName, rank_label AS rankLabel,
|
|
is_leader AS isLeader, is_online AS isOnline, user_id AS userId
|
|
FROM ${MEMBERS}
|
|
WHERE clan_id = ?
|
|
ORDER BY is_leader DESC, display_name`,
|
|
[clanId],
|
|
)
|
|
}
|
|
|
|
/**
|
|
* Replace what we know about one clan, in one transaction-shaped pair of writes.
|
|
*
|
|
* Called by whatever ingests from your sidecar; here, by `boot.js`. Delete-then-
|
|
* insert rather than an upsert, because a roster is a SET and the members who
|
|
* left are as much a part of the update as the ones who joined — an upsert leaves
|
|
* departed characters on the roster forever, and core would keep syncing them
|
|
* into a Team as present members.
|
|
*/
|
|
async function replaceClan({ externalId, name, abbr, memberCount, members }) {
|
|
await core.query(
|
|
`INSERT INTO ${CLANS} (external_id, name, abbr, member_count, updated_at)
|
|
VALUES (?, ?, ?, ?, CURRENT_TIMESTAMP)
|
|
ON DUPLICATE KEY UPDATE name = VALUES(name), abbr = VALUES(abbr),
|
|
member_count = VALUES(member_count), updated_at = CURRENT_TIMESTAMP`,
|
|
[externalId, name, abbr || null, memberCount],
|
|
)
|
|
await core.query(`DELETE FROM ${MEMBERS} WHERE clan_id = ?`, [externalId])
|
|
for (const m of members) {
|
|
await core.query(
|
|
`INSERT INTO ${MEMBERS} (clan_id, member_key, display_name, rank_label, is_leader, is_online, user_id)
|
|
VALUES (?, ?, ?, ?, ?, ?, ?)`,
|
|
[externalId, m.memberKey, m.displayName || null, m.rankLabel || null,
|
|
m.leader ? 1 : 0, m.online ? 1 : 0, m.userId || null],
|
|
)
|
|
}
|
|
}
|
|
|
|
/**
|
|
* The site accounts behind one clan's roster — the whole of an audience resolver.
|
|
*
|
|
* `user_id` is NULL for most characters, and the filter is the point: an audience
|
|
* resolves to PEOPLE WITH ACCOUNTS, and a character nobody has linked is not one.
|
|
* Returning its NULL would hand core a hole in an array it is about to mail.
|
|
*
|
|
* DISTINCT because one person may hold several characters in the same clan, and
|
|
* the resolver's contract is a set of users rather than a list of characters.
|
|
* Without it a three-character player is told three times.
|
|
*/
|
|
async function listMemberUserIds(clanId) {
|
|
const rows = await core.query(
|
|
`SELECT DISTINCT user_id AS userId
|
|
FROM ${MEMBERS}
|
|
WHERE clan_id = ? AND user_id IS NOT NULL`,
|
|
[clanId],
|
|
)
|
|
return rows.map((r) => r.userId)
|
|
}
|
|
|
|
module.exports = { listClans, findClan, listMembers, listMemberUserIds, replaceClan, CLANS, MEMBERS }
|