Remove container level treemaps #261
Conversation
Signed-off-by: Vanessa Sochat <vsochat@stanford.edu>
Signed-off-by: Vanessa Sochat <vsochat@stanford.edu>
Signed-off-by: Vanessa Sochat <vsochat@stanford.edu>
There was a problem hiding this comment.
This PR runs well on my side.
However, I am not sure that I see the new treemap.
To test, I have 2 collections, and a total of 3 containers. This is what the collections page shows me:
And when I click on a collection I get this (the button view is gone as expected I think):
Is it what I am supposed to see?
Also, when I go to tools/sizes (link provided on the index page and on the tool page) I get this:
This says that there are 0 container in 0 collection, while this is wrong. I am "staff" on django so I should be able to view all collections... especially mine.
Signed-off-by: Vanessa Sochat <vsochat@stanford.edu>
|
Ah - so for the container treemap, we do just show public collections, let me take a look at other permissions to see if staff/admin are allowed to see. |
|
Indeed, making my collections public shows the collections in the treemap view. |
Signed-off-by: Vanessa Sochat <vsochat@stanford.edu>
|
okay all set - I refactored the filter so that an admin/staff sees everything, and otherwise it's based on permissions (owner sees their own collections plus those of others that are public). |
|
It's working on my side! As a staff, I see all the collections and containers, and as a normal user I can only see the public collections. There is just something I don't understand, probably because I don't have the whole picture. Why do we need another library (singularity) to get the container size? Can't we use python to find the info (https://docs.python.org/3/library/os.path.html#os.path.getsize) as the files are actually hosted locally and the path/filenames are in the DB if I am correct? |
|
We don't - that was a very old implementation (years ago) that I had originally built in to use the singularity python module. I refactored it (also years ago) to not need this, and have all the views directly with the server. So, we don't require that dependency anymore, I had just forgotten :) |
|
@Aneoshun we can't do that because there are plugins for external storage that don't use the local filesystem. |
|
Ahh I see. I did not have the whole picture! Looks good to me then. |
|
Great! Thanks again for your help :) |
This PR will refactor the treemap to only show container counts per collection, and not size of containers - and we do this because not all avenues of adding a container support knowing the size.
@Aneoshun - it was actually the case that I had refactored the view to not rely on the third party (singularity) library, and it just wasn't showing up because the library pushed containers didn't have an associated size. It used to be that after a certain number of containers were added we flipped the view to show collection counts instead, so to fix this I removed the container level views and the variable, and now the map will just show collection sizes based on numbers of containers. The cron job was an artifact of a previous implementation that read in data from a json file -the rendered data for a few years now just comes from a csv dynamically rendered as a view (and I just forgot about it, heh).
Do you want to test this out? You should see a treemap for your collections based on containers per collection.