Is there a way I can query the DB to see a deleted case by case ID in the event that a user has deleted (not archived) a record, or is it no longer present in the DB?
The situation we have is that a client insists they have not deleted a record, but we have a case ID from an prior export (via API) that is no longer present in Commcare. This is a self-hosted instance.
The case will appear as deleted if someone has archived the form that created the case. There’s an admin interface called “raw doc” that you should be able to use to view the case if it was (soft) deleted:
Thanks Ethan, that’s really helpful. If the record doesn’t appear in the output from the raw doc search (but does appear in an earlier export via the API) can we assume it’s been (hard) deleted?
I just want to rule out some other issue since it seems that records within a 10 day window that were there at one point are no longer there. I guess I’d just like to confirm the events could have caused something like this. I assume it can’t be related to an es index problem.
I assume it can’t be related to an es index problem
That’s right - the raw doc search pulls from the primary SQL database, not elasticsearch.
Do you have a theory for how the case might’ve been deleted? I don’t believe there’s any such functionality available via the UI. Not sure what could’ve caused this situation.
Ah… now that’s what I wasn’t sure of. I was under the impression that records could first be archived then deleted (permanently) through the UI but if that’s not the case then we have a strange scenario. We have never had any event that would require any data restore etc. and when we do major work on the server, we take the system offline, create a snapshot of disks and after working, if there’s ever an issue, the snapshot is restored before the system is brought online again, so it would be where it was before the process started and there’s no way external devices can interact with the server.
I’ll do some digging, but this is one specific client missing records for a specific period only.
Could this have happened during one of the PostgreSQL upgrades perhaps? Though it seems unlikely.