I’m curious about the technicals of what happens in this situation.
Example:
You have a Classroom Data Type. There are dozens of other data types with properties that reference this, such as students, TAs, modules, assignments, sessions, etc. Some are lists, some are properties with a single Classroom.
When you delete a classroom but don’t go through and clean up all the references to it, what happens to the properties that reference it?
Are they seen as empty? If a list, is the list reduced by one? Is the reference eventually removed, or does it stay in there forever as an inaccessible ghost? Does it take more WU to delete an item with a lot of things referencing it than it does to delete an item that nothing is referencing?
Theoretically, this shouldn’t be a concern. As soon as the thing is removed, its references should be automatically removed. If it’s a reference in a simple field, it would be left empty, if it’s a reference in a list field, the list should be reduced.
However, I have noticed cases in the past where, when the reference is used in a list field, the reference is kept as an empty item. It’s difficult to replicate, but it has happened. Therefore, now, as a precaution, I remove it from the list before removing the final thing.
When you delete an item from the DB it’s gone - you don’t need to (in most cases) clean anything up that references it manually. Anything that referenced it previously will no longer reference it (i.e. those references will be set to null, and those fields will not appear in the retrieved data).
Are they seen as empty?
Yes.
If a list, is the list reduced by one?
Yes.
Is the reference eventually removed
It should be removed immediately*
or does it stay in there forever as an inaccessible ghost?
No
Does it take more WU to delete an item with a lot of things referencing it than it does to delete an item that nothing is referencing?
No
*There are some well discussed cases of so-called ‘ghost’ data - whereby deleted data does seem to hang around for a while (sometimes for days) - although not in an accessible form, which has caused some issues in the past - but it’s not supposed to be that way (and usually isn’t). It might be related to the number of related items.
As above, any references to it are treated as empty, and if it’s in the list, it will be removed. However, do watch out for the list example. If lists are long or it’s referenced in a list in many data types, what can happen is that it doesn’t get removed from the list. This means it’s treated as an entry in the list, but it’s actually an empty entry.
This is because lists of things in Bubble are just lists of unique IDs. Behind the scenes, the unique ID lookup reference in that list persists, but that thing doesn’t exist. So when you look it up, it’s empty, even though it counts toward the total of the list.
When this happens, do you get a list with :count x and an RG with length x-1? Does the reference to the deleted thing show up in any way other than the count?
Does it always get properly deleted eventually? Or can it stick around forever?
One really important thing to watch out for, is that if you delete a field without cleaning up it’s data first, it’s phantom data can still get pulled into the browser with searches & you can’t easily stop it happening. This can lead to all kind of nasty issues & security concerns. I really hope bubble fixed this issue but I’m not sure, so you just need careful.
Annoyingly, Bubble does not give us cascade options for deleting data - it defaults, as explained above, to setting related fields to null (and there’s no way to change that).
So if you need to delete related data, you’ll need to that manually.
What’s scary about that security issue is the optimize app function didn’t remove it either. Bubble should do a bit more around security for things like that, as I’m sure it’s nothing anybody would expect to have hanging around and being returned on fetch. Thanks for sharing.
Personally I felt it was related enough to warrant mentioning it and may even help save someone a lot of stress if they ever decide to delete something by deleting the entire field.
Phantom data is still an existing problem for lists and I had a ticket in with support a few months ago as it was starting to create issues in my app especially where I referenced counts on lists. The item was “empty,” but still existed in the list. It’s best practice to delete linked items as part of your workflow until this is “fixed.”
Their response is below:
“Given the nature of the behavior and the underlying logic, our engineers have a plan to address this in the longer term.
The original investigation has been closed, but we’re continuing to track related tickets to ensure any future fix is thorough. At this point, we’ll need to keep monitoring new reports, as addressing this fully would require significant engineering effort and is better suited for a longer-term solution.
We’ve set up a way to track similar reports for this behavior in particular, so we can share a full picture with our engineers as they work toward a fix.”
