I should be able to say what happens when I delete a pointed-to Thing
Summary: This comes up when we look at seriously importing MySQL, which allows you to specify in a foreign key constraint what happens if the Thing I point to gets deleted.
In chatting with Aaron, he mentions four options you can specify:
- Do Nothing: this is what Querki currently does, and is specifically not recommended in MySQL. For obvious reasons -- it allows you to easily wind up with an inconsistent DB. We're intentionally sloppy about that, but probably should become less so.
- Restrict: don't allow the Thing I'm pointing to to be deleted.
- Set to Null: that is, if the pointed-to Thing gets deleted, set this pointer to None. This makes sense so long as the pointers are Optional.
- Cascade: if the pointed-to Thing gets deleted, delete this Thing as well.
We should consider carefully whether we want to ape exactly these options. We very well might: MySQL's had lots of time to mature, so its options likely cover the desired use cases well.
MySQL allows these options on Update as well as Delete. It's less obvious whether that's relevant in Querki, since we have both hard Links and soft Tags. Using a Tag is effectively Do Nothing; using a Link is effectively Cascade. I'm not sure there's much motivation for Restrict or Set to Null in the Update case, but it's worth some thought.
Also, chew on what UI support is appropriate. For instance, if a Delete is going to cause cascading deletes, should we warn the user before proceeding? Should that be selectable via a meta-Property? "Restrict" might want to be replaced by "Choose" in our case -- explicitly ask the user which to do when I try to delete.
