When an existing entry is deleted from the database, it is removed from the refs table and moved to the deleted table. But as I see it, some of the data is actually stored in the table user_data. When the original record of the refs table is deleted, the linked entry in the user_data table remains untouched. Is this a bug or feature? Shouldn't it be automatically deleted, too, or at least moved to a table user_data_deleted?
Best regards, Karl-Heinz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Matthias is aware of this & includes a comment that states "(Note that if you delete the mother record within the 'refs' table, the corresponding child entry within the 'user_data' table will remain!)" Perhaps he will elaborate on his reasons, but I will put in my 2 cents.
The data should definitely not just be deleted--that violates the intention of using the deleted table (providing a recovery mechanism in the case of accidental deletion). Furthermore, I would argue that we should be even more careful with the user-specific data: though it impacts fewer people directly, this could be just as important & harder to re-enter (it is relatively easy to find citation information, but how do you recover someone's personal notes?).
An argument can be made that a user_data_deleted table might be valuable. Off the top of my head, there could be a few issues to resolve with this. Recovery/purging from the deleted table could be slightly complicated in that you now have two tables to keep "synced." Not unsurmountable obstacles by any means, but still factors to think of.
Right now, ease of recovery trumps keeping the user_data table small. I think this is a good choice: if there is a lot of user data on certain records, they are less likely to be intentionally deleted than records which aren't being used. I would support a user_data_deleted table or the ability to prune linked records from the user_data table when some (as-yet-unwritten) admin tool allowed records to be purged from the deleted table or some similar mechanism as long as recovery is as easy or easier than complete record removal.
-Rick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>When the original record of the refs table is deleted,
>the linked entry in the user_data table remains untouched.
>Is this a bug or feature?
Actually, it's both. ;-)
First of all, its a feature, since user data are crucial. As Rick correctly pointed out, deleted user data can be hardly recovered, if a user accidentally deletes a particular record. So I went for the easiest solution: _keep_ the user data. And if record data would be restored from the 'deleted' table, everything would be working again without any further hassle.
I had plans for an interface to the 'deleted' table, where the admin could browse deleted records and select records for recovery (or ultimate deletion). This hasn't been done yet, since there are other features which seem to be more important to me (like import & export capabilities).
Regarding removal of user data, I favor Rick's second solution:
>prune linked records from the user_data table when some (as-yet-unwritten)
>admin tool allowed records to be purged from the deleted table
I imagine that this interface would inform the admin about any user-specific data associated with a particular record of the 'deleted' table. The admin would have the choice to connect these user data entries with another record from the table 'refs' (which would be helpful in case of duplicate entries). Removing a record from the 'deleted' table would also (finally) remove all of its associated user data.
The bug is that this interface isn't there yet. ;-) And, frankly, I fear it'll take same time until this becomes reality. Too many other important things haven't been completed yet...
Best regards, Matthias
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see the difficulties with deleting user data. There will be no big problem as long as the database is small. But when you have many records and many users it will be very troublesome to keep the user data table clean just manually. It's fine when this point is put somewhere on the to-do list for future remembering after more important tasks have been finished.
Karl-Heinz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When an existing entry is deleted from the database, it is removed from the refs table and moved to the deleted table. But as I see it, some of the data is actually stored in the table user_data. When the original record of the refs table is deleted, the linked entry in the user_data table remains untouched. Is this a bug or feature? Shouldn't it be automatically deleted, too, or at least moved to a table user_data_deleted?
Best regards, Karl-Heinz
Matthias is aware of this & includes a comment that states "(Note that if you delete the mother record within the 'refs' table, the corresponding child entry within the 'user_data' table will remain!)" Perhaps he will elaborate on his reasons, but I will put in my 2 cents.
The data should definitely not just be deleted--that violates the intention of using the deleted table (providing a recovery mechanism in the case of accidental deletion). Furthermore, I would argue that we should be even more careful with the user-specific data: though it impacts fewer people directly, this could be just as important & harder to re-enter (it is relatively easy to find citation information, but how do you recover someone's personal notes?).
An argument can be made that a user_data_deleted table might be valuable. Off the top of my head, there could be a few issues to resolve with this. Recovery/purging from the deleted table could be slightly complicated in that you now have two tables to keep "synced." Not unsurmountable obstacles by any means, but still factors to think of.
Right now, ease of recovery trumps keeping the user_data table small. I think this is a good choice: if there is a lot of user data on certain records, they are less likely to be intentionally deleted than records which aren't being used. I would support a user_data_deleted table or the ability to prune linked records from the user_data table when some (as-yet-unwritten) admin tool allowed records to be purged from the deleted table or some similar mechanism as long as recovery is as easy or easier than complete record removal.
-Rick
Hi Karl-Heinz,
>When the original record of the refs table is deleted,
>the linked entry in the user_data table remains untouched.
>Is this a bug or feature?
Actually, it's both. ;-)
First of all, its a feature, since user data are crucial. As Rick correctly pointed out, deleted user data can be hardly recovered, if a user accidentally deletes a particular record. So I went for the easiest solution: _keep_ the user data. And if record data would be restored from the 'deleted' table, everything would be working again without any further hassle.
I had plans for an interface to the 'deleted' table, where the admin could browse deleted records and select records for recovery (or ultimate deletion). This hasn't been done yet, since there are other features which seem to be more important to me (like import & export capabilities).
Regarding removal of user data, I favor Rick's second solution:
>prune linked records from the user_data table when some (as-yet-unwritten)
>admin tool allowed records to be purged from the deleted table
I imagine that this interface would inform the admin about any user-specific data associated with a particular record of the 'deleted' table. The admin would have the choice to connect these user data entries with another record from the table 'refs' (which would be helpful in case of duplicate entries). Removing a record from the 'deleted' table would also (finally) remove all of its associated user data.
The bug is that this interface isn't there yet. ;-) And, frankly, I fear it'll take same time until this becomes reality. Too many other important things haven't been completed yet...
Best regards, Matthias
Hello Matthias and Rick,
I see the difficulties with deleting user data. There will be no big problem as long as the database is small. But when you have many records and many users it will be very troublesome to keep the user data table clean just manually. It's fine when this point is put somewhere on the to-do list for future remembering after more important tasks have been finished.
Karl-Heinz