[ENHANCEMENT]: Make it possible to archive cracks

[jessevz]

Description

Currently, the show cracks page can be very slow if you have a lot of cracks on your system. You can add an index on time cracked which should already help (I haven't tested how much faster it becomes yet). But if you have a lot of cracks, you are probably not interested in a lot of the old cracks, but still want them on your system. It makes sense to be able to archive old cracks you do not currently need anymore, so that queries for newly cracked hashes become faster (if there is an index on the archived flag).
Then it probably makes sense in the frontend if you can archive cracks by selecting a time and archive all cracks before that time and have the option that when you archive a task, also archive the hashes found in that task (but not by default).

[s3inlc]

Couldn't it just be the way that on the default cracks page (meaning no hashlist or task specified) only cracks of non-archived hashlists/tasks are shown?
If people would like to see cracks from archived stuff, they probably should just go to that task/hashlist and access the cracks through there.

[jessevz]

Couldn't it just be the way that on the default cracks page (meaning no hashlist or task specified) only cracks of non-archived hashlists/tasks are shown? If people would like to see cracks from archived stuff, they probably should just go to that task/hashlist and access the cracks through there.

@s3inlc I dont think this will result into a speedup, since you cant really get the speed up from an indexed isArchived field that way. But i can first test how much better it performs with the additional timeCracked index. if that performs good, we can probably keep it this way

[s3inlc]

I think there should already be indexes over the columns chunkId and hashlistId which I think should make it quite fast to only query the non-archived ones via a join statement, no?

[jessevz]

@s3inlc I am not 100% sure, but I think if you go that route you need on both task and hashlist a composite index on the primary key + isArchived to most efficiently make use of the indexing. The other problem is that with he new API it is not possible to filter on data of the included object so we have to find a solution for that aswell.

[jessevz]

And now that I think of it, in Hashes, the time cracked and isCracked should probably also be a composite index instead of seperate indexes