Excessive calls to /meta on dataset landing pages

[amoeba]

When browsing https://arcticdata.io/catalog/view/urn:uuid:6b76bdb0-d080-43e7-bb24-12f0d5b34654, I notice my browser hangs a fair bit and I also notice about 1000+ calls to /meta for various Objects. The package has 999 members (The ORE in question is resource_map_urn:uuid:6b76bdb0-d080-43e7-bb24-12f0d5b34654).

It looks like the performance of this page is related in part to the excessive calls to /meta (there should be only one or two at the most) and possibly a large response from the View Service (~2.6MB of HTML which is a lot).

[jagoldstein]

Yes, I concur with @amoeba about the UX. Landing pages for packages with ORE's that aggregate 100s of objects are very slow to render and often fail.

Here's another example:
https://doi.org/10.18739/A2SJ19R0S
.

[laurenwalker]

I agree that this issue needs to be resolved. This was introduced when the prov charts were refactored to use the new DataPackage collection, which retrieves the system metadata for all members of a package during fetch(). But it's not necessary.

[laurenwalker]

I just pushed a fix for this issue that makes loading of large datasets much faster. Particularly, the delay to show the prov charts should be reduced by orders of magnitude. Here's a screengrab showing the difference between my updated local MetacatUI and the unupdated MetacatUI on dev.nceas for a 300-member package:

Summary of the solution

• The only thing the ProvChartViews need from the system metadata is the formatId and fileName. These are both indexed and already retrieved when the PackageTableView is rendered at the top of the page. I added some code that allows the ProvChartViews to reuse that information instead of retrieving it from the system metadata.

[amoeba]

Awesome, thanks for doing this @laurenwalker !