The database contains many orphaned objects. For example, under the Taxa tab, search on NCBI taxid 114498, then click either the Trees or Matrices tabs. This results in records even though none of them belong to an existing study. The problem is in part because trees and matrices don't actually get deleted properly: create a submission, upload trees or matrices, then delete the trees or matrices -- the only thing that is deleted is the linking record in the sub_matrix table. None of the column records, row records, or element records (etc) seem to get deleted. Youjun explained that the design of the matrix object does not allow the code to access the matrix rows (etc) for easy deletion. One possible solution is to include cascade-delete constraints on the tables so that deleting a matrix record automatically delete all related records without leaving behind any orphans. At any rate, it behooves us to prevent the accumulation of orphans and to write data cleansers to get rid of the existing ones.
The database contains many orphaned objects. For example, under the Taxa tab, search on NCBI taxid 114498, then click either the Trees or Matrices tabs. This results in records even though none of them belong to an existing study. The problem is in part because trees and matrices don't actually get deleted properly: create a submission, upload trees or matrices, then delete the trees or matrices -- the only thing that is deleted is the linking record in the sub_matrix table. None of the column records, row records, or element records (etc) seem to get deleted. Youjun explained that the design of the matrix object does not allow the code to access the matrix rows (etc) for easy deletion. One possible solution is to include cascade-delete constraints on the tables so that deleting a matrix record automatically delete all related records without leaving behind any orphans. At any rate, it behooves us to prevent the accumulation of orphans and to write data cleansers to get rid of the existing ones.
Reported by: piel