PRACTICAL FIELD GUIDE
Renaming a column can break generated clients
A schema rename changes the field and filter names that API callers use. Coordinate the database change with deployed clients rather than treating it as a dashboard-only edit.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Find every request, form and response parser that references the old field.
- Choose a compatibility rollout or controlled cutover appropriate to your clients.
- Refresh the generated contract and test reads, writes, sorting and filtering with the new name.
What this looks like
ILLUSTRATIVE EXAMPLE
A mobile client continues sending due_date after the column becomes deadline. The generated API correctly rejects the unknown field.
A boundary to keep clear
Old browser tabs and released mobile apps can outlive a deployment. Account for those clients before removing a field they still use.
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.