Companion to dc/dc#352, which changes getdata to serve a selection over DC_MAXOBS_WEBEDIT / DC_MAXCELLS_WEBEDIT truncated instead of refusing it with Table is too big.
dcc-options.md - both EDIT limits now truncate and show a warning triangle next to the table name.
developer-guide/filter-pre-edit-hook.md - the row cap paragraph described the abort; also corrected the stated default (500 -> 250, the value the code and MPE_CONFIG actually ship).
developer-guide/two-rule-sets-one-table.md - same abort wording.
Merge with the code change, not before it: the pages describe what a release does, and no release carries the truncation yet.
Companion to dc/dc#352, which changes `getdata` to serve a selection over `DC_MAXOBS_WEBEDIT` / `DC_MAXCELLS_WEBEDIT` truncated instead of refusing it with *Table is too big*.
- `dcc-options.md` - both EDIT limits now truncate and show a warning triangle next to the table name.
- `developer-guide/filter-pre-edit-hook.md` - the row cap paragraph described the abort; also corrected the stated default (500 -> 250, the value the code and MPE_CONFIG actually ship).
- `developer-guide/two-rule-sets-one-table.md` - same abort wording.
Merge with the code change, not before it: the pages describe what a release does, and no release carries the truncation yet.
getdata no longer refuses a selection over DC_MAXOBS_WEBEDIT or
DC_MAXCELLS_WEBEDIT - it serves the rows within the limit and flags the
truncation against the table name. Update the option reference and the two
developer-guide pages that claimed the edit screen stops with "Table is too
big". The hook page also carried the old 500 row default.
Reviewed the full base...head diff: the dcc-options EDIT-limit sections and the two developer-guide pages that described the old abort, checked for other stale limit/abort wording across docs/, and confirmed the described behaviour (truncated grid, warning against the table name, filter to see the rest) matches the companion dc/dc#352 implementation.
docs/developer-guide/filter-pre-edit-hook.md:149 - the corrected paragraph says getdata truncates "to the rows within the limit, and warns against the table name", but the cap is not just DC_MAXOBS_WEBEDIT: DC_MAXCELLS_WEBEDIT is applied at the same time, and for a wide table it binds first (floor(cells / columns) rows). A hook author reading only this page would check row count alone and miss the cell cap that actually truncates them - dcc-options.md's own DC_MAXOBS_WEBEDIT section (line 38) says "increase both together" for exactly that reason. Say "either DC_MAXOBS_WEBEDIT or DC_MAXCELLS_WEBEDIT" here, matching the two-rule-sets page's wording.
docs/developer-guide/filter-pre-edit-hook.md:149 (same line, secondary) - "the rows past the limit never reach the browser" is now accurate, but the preceding clause still says "(250 by default)" for the row limit while the actual cap for a wide table can be far lower; a hook author widening a filter on a 100-column table hits the cell cap at floor(200000/100) = 2000 rows only if DC_MAXOBS_WEBEDIT was raised - the interaction is exactly what the hook author needs to reason about. One clause covering both limits resolves this and the point above together.
No blocking issues beyond the two wording items above; both are on the same line, so it is one edit.
Reviewed the full base...head diff: the dcc-options EDIT-limit sections and the two developer-guide pages that described the old abort, checked for other stale limit/abort wording across docs/, and confirmed the described behaviour (truncated grid, warning against the table name, filter to see the rest) matches the companion dc/dc#352 implementation.
- docs/developer-guide/filter-pre-edit-hook.md:149 - the corrected paragraph says getdata truncates "to the rows within the limit, and warns against the table name", but the cap is not just DC_MAXOBS_WEBEDIT: DC_MAXCELLS_WEBEDIT is applied at the same time, and for a wide table it binds first (floor(cells / columns) rows). A hook author reading only this page would check row count alone and miss the cell cap that actually truncates them - dcc-options.md's own DC_MAXOBS_WEBEDIT section (line 38) says "increase both together" for exactly that reason. Say "either DC_MAXOBS_WEBEDIT or DC_MAXCELLS_WEBEDIT" here, matching the two-rule-sets page's wording.
- docs/developer-guide/filter-pre-edit-hook.md:149 (same line, secondary) - "the rows past the limit never reach the browser" is now accurate, but the preceding clause still says "(250 by default)" for the row limit while the actual cap for a wide table can be far lower; a hook author widening a filter on a 100-column table hits the cell cap at floor(200000/100) = 2000 rows only if DC_MAXOBS_WEBEDIT was raised - the interaction is exactly what the hook author needs to reason about. One clause covering both limits resolves this and the point above together.
No blocking issues beyond the two wording items above; both are on the same line, so it is one edit.
The truncation is whichever of DC_MAXOBS_WEBEDIT and DC_MAXCELLS_WEBEDIT
binds first, and for a wide table it is the cell cap - floor(cells/columns)
rows, potentially far below the row limit. The hook page named only the row
cap and quoted its 250 default, so a hook author would check the row count
alone. Same correction in the two-rule-sets page.
getdata truncates a result over either DC_MAXOBS_WEBEDIT or DC_MAXCELLS_WEBEDIT, whichever binds first - a wide table runs out of cells before rows, at floor(cells / columns) rows - and warns against the table name. Widening a filter widens the result, so a hook that adds a quarter can push a table over the cap: the rows past the limit never reach the browser. Check both counts before handing the data back, or raise the options for that table in MPE_CONFIG.
The section heading is now "The row and cell caps" (no anchors point at the old one), the "(250 by default)" clause is gone, and "both counts" replaces "the count".
Same correction applied to the sentence in two-rule-sets-one-table.md that named only the row cap, so the two pages agree.
Both items were the one line - fixed in 561e92e:
`getdata` truncates a result over either `DC_MAXOBS_WEBEDIT` or `DC_MAXCELLS_WEBEDIT`, whichever binds first - a wide table runs out of cells before rows, at floor(cells / columns) rows - and warns against the table name. Widening a filter widens the result, so a hook that adds a quarter can push a table over the cap: the rows past the limit never reach the browser. Check both counts before handing the data back, or raise the options for that table in `MPE_CONFIG`.
The section heading is now "The row and cell caps" (no anchors point at the old one), the "(250 by default)" clause is gone, and "both counts" replaces "the count".
Same correction applied to the sentence in `two-rule-sets-one-table.md` that named only the row cap, so the two pages agree.
Reviewed the full base...head diff at the new head - the dcc-options truncation note, the two developer-guide pages, the rest of docs/ for stale limit or abort wording, and the companion dc/dc#352 implementation the pages describe (row cap = min(DC_MAXOBS_WEBEDIT, floor(DC_MAXCELLS_WEBEDIT / columns)), TRUNCATED / TRUNC_MSG driving the warning against the table name).
docs/dc-overview.md:38 - "Up to 500 rows can be edited (in the web editor) at one time" states the wrong figure and, once dc/dc#352 lands, the wrong behaviour: the DC_MAXOBS_WEBEDIT default is 250 (dcc-options.md:31, and the value the code and MPE_CONFIG ship), and an over-limit EDIT selection is then served truncated with a warning rather than capped at a row count. The page is outside the diff but squarely inside this PR's purpose (correcting stale EDIT-limit documentation) - cover it in the same pass.
1 finding above for review.
Reviewed the full base...head diff at the new head - the dcc-options truncation note, the two developer-guide pages, the rest of docs/ for stale limit or abort wording, and the companion dc/dc#352 implementation the pages describe (row cap = min(DC_MAXOBS_WEBEDIT, floor(DC_MAXCELLS_WEBEDIT / columns)), TRUNCATED / TRUNC_MSG driving the warning against the table name).
- docs/dc-overview.md:38 - "Up to 500 rows can be edited (in the web editor) at one time" states the wrong figure and, once dc/dc#352 lands, the wrong behaviour: the DC_MAXOBS_WEBEDIT default is 250 (dcc-options.md:31, and the value the code and MPE_CONFIG ship), and an over-limit EDIT selection is then served truncated with a warning rather than capped at a row count. The page is outside the diff but squarely inside this PR's purpose (correcting stale EDIT-limit documentation) - cover it in the same pass.
1 finding above for review.
Review 431: dc-overview.md still said "Up to 500 rows can be edited (in the web
editor) at one time" - the wrong number (DC_MAXOBS_WEBEDIT ships at 250) and, once
dc/dc#352 lands, the wrong behaviour (an over-limit selection is served truncated
with a warning, not refused or capped at a count). It now names both limits,
whichever binds first, and links to the options that set them.
Sweeping for the same stale figure turned up dcu-tableviewer.md, which says 500
twice and uses 500 in its worked example of the row count above the grid.
DC_MAXOBS_WEBVIEW has been 2000 since 20261003_row_and_cell_limits.sas (the
migration records 500 -> 2000), and mpe_makedata seeds 2000, so those three
places were two releases out of date. Fixed here, and flagged in the PR reply as
VIEW rather than EDIT in case it belongs in its own change.
Checked: no "500 rows" or stale abort wording left in docs/, and the two anchors
the overview now links to (dc_maxobs_webedit, dc_maxcells_webedit) exist on the
published options page.
856e571 answers this, and the sweep the finding implies turned up one more.
dc-overview.md:38 - you are right on both counts. It said "Up to 500 rows can be edited (in the web editor) at one time", which is the wrong figure (DC_MAXOBS_WEBEDIT ships at 250) and, once dc/dc#352 lands, the wrong behaviour. It now reads:
The EDIT screen loads up to DC_MAXOBS_WEBEDIT rows (250 by default), or as many rows as fit within DC_MAXCELLS_WEBEDIT (200,000 cells) - whichever is reached first, so a wide table loads fewer rows than a narrow one. A larger table is not refused: it loads truncated, with a warning against the table name, and the filter is the way to reach the rest.
with links to both options.
The extra one, from sweeping docs/ for the same stale figure:dcu-tableviewer.md says 500 twice, and uses 500 in its worked example of the count above the grid. DC_MAXOBS_WEBVIEW has been 2000 since 20261003_row_and_cell_limits.sas - the migration itself records |DC_MAXOBS_WEBVIEW|500|2000| - and mpe_makedata seeds 2000, so those three statements were two releases out of date. Fixed to 2,000, with the example moved to a 5,000-row table holding the first 2,000.
That is VIEW rather than EDIT, so if you would rather it went in its own change, say so and I will split it out of this branch - it is one commit and trivially separable.
Checked afterwards: no 500 rows or stale abort wording left anywhere in docs/, and the two anchors the overview now links to (dc_maxobs_webedit, dc_maxcells_webedit) both exist on the published options page.
856e571 answers this, and the sweep the finding implies turned up one more.
**dc-overview.md:38** - you are right on both counts. It said "Up to 500 rows can be edited (in the web editor) at one time", which is the wrong figure (DC_MAXOBS_WEBEDIT ships at 250) and, once dc/dc#352 lands, the wrong behaviour. It now reads:
> The EDIT screen loads up to DC_MAXOBS_WEBEDIT rows (250 by default), or as many rows as fit within DC_MAXCELLS_WEBEDIT (200,000 cells) - whichever is reached first, so a wide table loads fewer rows than a narrow one. A larger table is not refused: it loads truncated, with a warning against the table name, and the filter is the way to reach the rest.
with links to both options.
**The extra one, from sweeping docs/ for the same stale figure:** `dcu-tableviewer.md` says 500 twice, and uses 500 in its worked example of the count above the grid. DC_MAXOBS_WEBVIEW has been 2000 since `20261003_row_and_cell_limits.sas` - the migration itself records `|DC_MAXOBS_WEBVIEW|500|2000|` - and `mpe_makedata` seeds 2000, so those three statements were two releases out of date. Fixed to 2,000, with the example moved to a 5,000-row table holding the first 2,000.
That is VIEW rather than EDIT, so if you would rather it went in its own change, say so and I will split it out of this branch - it is one commit and trivially separable.
Checked afterwards: no `500 rows` or stale abort wording left anywhere in docs/, and the two anchors the overview now links to (`dc_maxobs_webedit`, `dc_maxcells_webedit`) both exist on the published options page.
allan
merged commit ca62bb391c into main2026-10-26 11:59:55 +00:00
allan
deleted branch docs/editor-limit-warning2026-10-26 11:59:55 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
hermes
Companion to dc/dc#352, which changes
getdatato serve a selection overDC_MAXOBS_WEBEDIT/DC_MAXCELLS_WEBEDITtruncated instead of refusing it with Table is too big.dcc-options.md- both EDIT limits now truncate and show a warning triangle next to the table name.developer-guide/filter-pre-edit-hook.md- the row cap paragraph described the abort; also corrected the stated default (500 -> 250, the value the code and MPE_CONFIG actually ship).developer-guide/two-rule-sets-one-table.md- same abort wording.Merge with the code change, not before it: the pages describe what a release does, and no release carries the truncation yet.
Reviewed the full base...head diff: the dcc-options EDIT-limit sections and the two developer-guide pages that described the old abort, checked for other stale limit/abort wording across docs/, and confirmed the described behaviour (truncated grid, warning against the table name, filter to see the rest) matches the companion dc/dc#352 implementation.
docs/developer-guide/filter-pre-edit-hook.md:149 - the corrected paragraph says getdata truncates "to the rows within the limit, and warns against the table name", but the cap is not just DC_MAXOBS_WEBEDIT: DC_MAXCELLS_WEBEDIT is applied at the same time, and for a wide table it binds first (floor(cells / columns) rows). A hook author reading only this page would check row count alone and miss the cell cap that actually truncates them - dcc-options.md's own DC_MAXOBS_WEBEDIT section (line 38) says "increase both together" for exactly that reason. Say "either DC_MAXOBS_WEBEDIT or DC_MAXCELLS_WEBEDIT" here, matching the two-rule-sets page's wording.
docs/developer-guide/filter-pre-edit-hook.md:149 (same line, secondary) - "the rows past the limit never reach the browser" is now accurate, but the preceding clause still says "(250 by default)" for the row limit while the actual cap for a wide table can be far lower; a hook author widening a filter on a 100-column table hits the cell cap at floor(200000/100) = 2000 rows only if DC_MAXOBS_WEBEDIT was raised - the interaction is exactly what the hook author needs to reason about. One clause covering both limits resolves this and the point above together.
No blocking issues beyond the two wording items above; both are on the same line, so it is one edit.
Both items were the one line - fixed in
561e92e:getdatatruncates a result over eitherDC_MAXOBS_WEBEDITorDC_MAXCELLS_WEBEDIT, whichever binds first - a wide table runs out of cells before rows, at floor(cells / columns) rows - and warns against the table name. Widening a filter widens the result, so a hook that adds a quarter can push a table over the cap: the rows past the limit never reach the browser. Check both counts before handing the data back, or raise the options for that table inMPE_CONFIG.The section heading is now "The row and cell caps" (no anchors point at the old one), the "(250 by default)" clause is gone, and "both counts" replaces "the count".
Same correction applied to the sentence in
two-rule-sets-one-table.mdthat named only the row cap, so the two pages agree.Reviewed the full base...head diff at the new head - the dcc-options truncation note, the two developer-guide pages, the rest of docs/ for stale limit or abort wording, and the companion dc/dc#352 implementation the pages describe (row cap = min(DC_MAXOBS_WEBEDIT, floor(DC_MAXCELLS_WEBEDIT / columns)), TRUNCATED / TRUNC_MSG driving the warning against the table name).
1 finding above for review.
856e571answers this, and the sweep the finding implies turned up one more.dc-overview.md:38 - you are right on both counts. It said "Up to 500 rows can be edited (in the web editor) at one time", which is the wrong figure (DC_MAXOBS_WEBEDIT ships at 250) and, once dc/dc#352 lands, the wrong behaviour. It now reads:
with links to both options.
The extra one, from sweeping docs/ for the same stale figure:
dcu-tableviewer.mdsays 500 twice, and uses 500 in its worked example of the count above the grid. DC_MAXOBS_WEBVIEW has been 2000 since20261003_row_and_cell_limits.sas- the migration itself records|DC_MAXOBS_WEBVIEW|500|2000|- andmpe_makedataseeds 2000, so those three statements were two releases out of date. Fixed to 2,000, with the example moved to a 5,000-row table holding the first 2,000.That is VIEW rather than EDIT, so if you would rather it went in its own change, say so and I will split it out of this branch - it is one commit and trivially separable.
Checked afterwards: no
500 rowsor stale abort wording left anywhere in docs/, and the two anchors the overview now links to (dc_maxobs_webedit,dc_maxcells_webedit) both exist on the published options page.