035419fa51
The scanner has been reporting the same count for weeks, which is what a rule that only prints becomes. It now FAILS the build, and it looks where the leaks actually were: PowerShell, the installer, the seeds, generated JSON, the frontend - case-insensitively, across plugins, shopdb, scripts, deploy, tools. A line that is deliberate declares itself with an ADR-015-OK marker and a reason, so the claim is visible in review instead of tolerated in silence. What it found, fixed here: - The shadow client wrote one site's ShopDB URL into HKLM whenever the registry disagreed. At the site it was written for that reads as healing drift; anywhere else it overwrites the site's own address on every enforce cycle, and the site cannot win because the cycle repeats. The bay's value now wins, an explicit -BaseUrl seeds it, and with neither there is nothing honest to write, so it says so and skips. - The kiosk dispatcher fell back to one plant's host when HKLM was unset, so a kiosk elsewhere quietly opened a server it has no business reaching. The fallback is now this site's site_base_url, baked in at seed time, and the dispatcher refuses rather than guessing when neither is set. Its legacy shortcut matcher derives the host from that URL instead of naming one. - The OpenAPI generator hardcoded a production hostname into every spec it generated, which then published to a public wiki. The relative mount is the only server it can honestly name; a site passes its own by environment. - Placeholders and examples in the UI and the client help offered real internal subnets and a real production URL. They now use documentation ranges. Both publication gates - the export scrub and the docs publishability test - carry the site patterns, which neither did. One plant's hostname, FQDN and internal networks are out of the documentation and the generated specs. Comments naming the reference site are reworded rather than deleted: the reasoning is worth keeping, the plant name is not what makes it true.
41 lines
1.8 KiB
Python
41 lines
1.8 KiB
Python
"""Force every table created on MySQL to utf8mb4 + DYNAMIC row format.
|
|
|
|
Importing this module installs a SQLAlchemy compiler hook. It is a side effect on
|
|
purpose: the hook has to be registered before any CreateTable is compiled, and
|
|
every place that creates tables needs it.
|
|
|
|
WHY. Without it a CREATE TABLE inherits the SERVER's default charset. A MySQL box
|
|
defaulting to latin1 - common on older installs, and the 5.6 server this was
|
|
ported from is one - silently builds a latin1 schema that drifts from the utf8mb4
|
|
production target. Nothing fails at create time; it surfaces later as mangled
|
|
characters, or as a join between a utf8mb4 and a latin1 column that cannot use an
|
|
index.
|
|
|
|
DYNAMIC row format is the other half: it keeps utf8mb4 indexes under the 767-byte
|
|
prefix limit on pre-5.7 InnoDB, which is what error 1071 ("key too long") is.
|
|
|
|
This lived inline in migrations/env.py, so it covered the CORE chain only. Plugin
|
|
chains (ADR-008) run through shopdb/plugins/alembic_template.py, which never
|
|
imported it - so a plugin's baseline tables were created at the server default
|
|
while core's were utf8mb4, on the same database. Both import this now.
|
|
|
|
Scoped to the mysql dialect, so the SQLite test database is untouched.
|
|
"""
|
|
from sqlalchemy.ext.compiler import compiles
|
|
from sqlalchemy.schema import CreateTable
|
|
|
|
TABLE_SUFFIX = (
|
|
" ENGINE=InnoDB DEFAULT CHARSET=utf8mb4"
|
|
" COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC"
|
|
)
|
|
|
|
|
|
@compiles(CreateTable, "mysql")
|
|
def _mysql_create_table_utf8mb4(element, compiler, **kw):
|
|
sql = compiler.visit_create_table(element, **kw)
|
|
# An explicit CHARSET in the model's __table_args__ wins - this is a default,
|
|
# not an override.
|
|
if "CHARSET" not in sql.upper():
|
|
sql = sql.rstrip().rstrip(";") + TABLE_SUFFIX
|
|
return sql
|