PRACTICAL FIELD GUIDE
Review cascading deletes before enabling them
A cascading relationship can remove dependent rows when a parent is deleted. That behavior needs an explicit product decision and a test using disposable data.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- List the parent-child chain and identify which records should survive a parent deletion.
- Choose an appropriate supported referential action and document the intended outcome.
- Delete a test parent and inspect all dependent tables before approving the schema.
What this looks like
ILLUSTRATIVE EXAMPLE
Deleting a sample collection also deletes its items under CASCADE. That may be correct for drafts and wrong for records you must retain.
A boundary to keep clear
Do not test destructive relationships against production records just to discover how the schema behaves.
MCPBackend context
MCPBackend stores each project's data in SQLite and exposes supported tables through generated REST endpoints. Use the schema tools and dashboard for supported changes. The design examples here are patterns to adapt, not claims that the API exposes every SQLite feature or arbitrary SQL.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.