NocoBase's 2.2.14 upgrade adds 44 columns, 42 of them in four new tables

The two columns that land on existing tables are `workflows.invalid`, a boolean, and `aiConversations.scope`, a character varying ^[7]. The upgrade also writes rows. `uiLayouts` and `desktopRoutesUiLayouts` are new in 2.2, and after the in-place upgrade neither was empty ^[17]. `uiLayouts` held `admin-layout-model` for desktop and `mobile-layout-model` for mobile. `desktopRoutesUiLayouts` mapped both existing routes to `admin-layout-model` ^[17]. Three migrations in the `ui-layout` plugin do this. `ensure-default-admin-layout` creates the two layouts, and `backfill-admin-layout-desktop-routes` attaches every route in `desktopRoutes` that has no layout yet. `backfill-late-admin-layout-desktop-routes` then runs the same backfill again later ^[18].

A page built in the admin UI does not go into `uiSchemas`. It goes into `flowModels`, and its route has a different type ^[12]. `flowModels` has three columns, `uid`, `name` and a JSON `options`, and the whole page tree lives in that JSON ^[14]. The author's one-block page came to eight rows ^[14]. The binding to the collection sits in `stepParams`, where `resourceSettings.init` names `dataSourceKey` "main" and `collectionName` "items" ^[15].

`uiSchemas` is the older engine, and the UI does not write to it ^[13]. According to the author, inserting a Page, Grid, Grid.Row, Grid.Col, CardItem hierarchy into `uiSchemas` and pointing a `type: "page"` route at it gives a working menu entry with a blank body, on 2.1.39 and 2.2.14 alike ^[13]. The page exists in the sense that it has a menu entry. The author built the test page through the UI for this reason. "Writing the schema straight through the API would have been faster, and it would not have been a valid test," the author wrote ^[11].

The author's check is a hash per row: `select uid, md5(options::text) from "flowModels" order by uid;`, run before the upgrade and again after ^[16]. Row counts alone will not show whether a definition was rewritten ^[16]. An md5 of `options` changes when any byte of that JSON changes, so a rewritten page shows up as a new digest on the same `uid`.

The clean page result comes from a small workload. The test page had one collection of three rows, one table block and one visible column ^[9], running on official Docker images with PostgreSQL 16 ^[5]. For the result to transfer, a production instance's pages would need to live in `flowModels` the same way, and its plugins would need to leave those rows alone during migration. The forum user who asked for a matrix is on 2.1.30 ^[2], nine patch numbers below the tested starting point ^[20]. One reply in that thread came from someone who upgrades every version in order and never skips one, "for fear of problems" ^[3]. The test did the opposite, with one in-place jump from 2.1.39 to 2.2.14 ^[5].