mxcli version: v0.24.0 and main (f18c3077)
Summary
DROP USER ROLE, DROP DEMO USER, ALTER ENTITY … DROP ATTRIBUTE and ALTER ENUMERATION … DROP VALUE take IF EXISTS. The document-level DROP statements do not: DROP LAYOUT, DROP PAGE, DROP ENTITY, DROP MICROFLOW, DROP SNIPPET and the rest of dropStatement, about 40 alternatives. A script that removes a document therefore works exactly once. On every later run it stops at the DROP, and every statement after it is skipped.
Where it came up
An agent moved an app from hand-built layouts to a stock Atlas layout: it repointed the pages, then ran drop layout Module.Employee_Shell; and so on. On the next run of the same script, which was needed to add menu icons, it stopped at the first drop layout. The agent probed drop layout if exists …, got a parse error, and ended up deleting the drop lines from its script by hand. The script is no longer a record of what was done to the model.
The grammar already says why this matters, above dropUserRoleStatement: "IF EXISTS makes a cleanup script re-runnable. Without it the statement fails the second time, so a one-time cleanup either breaks every later run of the slice or has to be commented out."
Proposal
Allow DROP <kind> [IF EXISTS] qualifiedName for the document kinds in dropStatement, using the existing ifExists rule. A missing document then reports skipped: <kind> <name> does not exist instead of failing. Without IF EXISTS, behaviour is unchanged.
Is this something you would take? If so, I would start with the document kinds that scripts actually drop (entity, association, enumeration, constant, microflow, nanoflow, page, layout, snippet, menu, image collection, java action), with a test per kind, and add the rest the same way.
mxcli version: v0.24.0 and main (
f18c3077)Summary
DROP USER ROLE,DROP DEMO USER,ALTER ENTITY … DROP ATTRIBUTEandALTER ENUMERATION … DROP VALUEtakeIF EXISTS. The document-levelDROPstatements do not:DROP LAYOUT,DROP PAGE,DROP ENTITY,DROP MICROFLOW,DROP SNIPPETand the rest ofdropStatement, about 40 alternatives. A script that removes a document therefore works exactly once. On every later run it stops at theDROP, and every statement after it is skipped.Where it came up
An agent moved an app from hand-built layouts to a stock Atlas layout: it repointed the pages, then ran
drop layout Module.Employee_Shell;and so on. On the next run of the same script, which was needed to add menu icons, it stopped at the firstdrop layout. The agent probeddrop layout if exists …, got a parse error, and ended up deleting thedroplines from its script by hand. The script is no longer a record of what was done to the model.The grammar already says why this matters, above
dropUserRoleStatement: "IF EXISTS makes a cleanup script re-runnable. Without it the statement fails the second time, so a one-time cleanup either breaks every later run of the slice or has to be commented out."Proposal
Allow
DROP <kind> [IF EXISTS] qualifiedNamefor the document kinds indropStatement, using the existingifExistsrule. A missing document then reportsskipped: <kind> <name> does not existinstead of failing. WithoutIF EXISTS, behaviour is unchanged.Is this something you would take? If so, I would start with the document kinds that scripts actually drop (entity, association, enumeration, constant, microflow, nanoflow, page, layout, snippet, menu, image collection, java action), with a test per kind, and add the rest the same way.