How the database follows the shape
The project keeps two copies of the shape: the one you’re drawing, and the applied one the database has. After every edit, if the drawn shape is valid, the app works out the difference and runs it:
| You | The app runs |
|---|---|
| add a type | CREATE NODE TABLE with its columns |
| add a property | ALTER TABLE … ADD |
| rename a type or property | ALTER TABLE … RENAME |
| change a Text to an Enum or back | nothing: both are STRING |
| add a connection to a relationship | the relationship table is rebuilt with the new pair, and its rows copied across |
| delete a type, property or connection | DROP, after asking when data would go |
| set or change a default | an UPDATE that fills nodes without a value (and those still holding the old default) |
| rename an enum option | an UPDATE that rewrites the stored word |
Graph and Ask always work against the applied shape, never against unapplied edits, so you can’t query a column that doesn’t exist yet.
What waits
Edits wait while the shape has issues (the capsule says Not saved yet and lists them on hover): a type or property without a name, duplicate property names in a type, two types or relationships resolving to the same identifier, a property named id, a relationship connecting nothing. The moment the last issue is fixed, everything pending applies.
What asks first
Anything that would delete values:
- deleting a type with nodes (“Its 12 nodes and 30 connections are deleted from your graph too”),
- deleting a relationship type or one of its connections with connections in it,
- turning off a direction that holds connections,
- deleting a property with values.
Each sheet ends “This can’t be undone.” Deleting something empty asks nothing and stays undoable.
Undo
Every shape edit is an undo step named after what it did (Add Node Type, Rename Property, Change Direction, Embed Property, Edit Options…). Undo stops at the point where going back would delete data that’s been added since: “Undo stopped here: going further would delete data from your graph. Delete it directly if you mean to.” After a lossy change the undo history is cleared.
Kinds are sticky
A property’s kind is fixed once the graph holds a value for it (Text ↔ Enum excepted), because changing it would wipe those values. Everything else about a property can change at any time.
Embedded text follows along
Switching a Text property’s embedding on or off, renaming it, or deleting it tells the embedding reconciler to plan again: vectors for a renamed property are kept (they’re keyed by the property’s id, not its name), vectors for a dropped property are removed, and a newly embedded property is embedded in the background.
Why no finalize? Earlier versions locked the shape after a review sheet created the tables. LadybugDB supports ALTER TABLE, so the app now keeps the database in step continuously and only ever has to ask about deletions.