11081
Reporter: trobertson
Assignee: omeyn
Type: Improvement
Summary: Stop eager loading of primary resources
Priority: Blocker
Resolution: Fixed
Status: Closed
Created: 2012-05-11 17:54:16.394
Updated: 2013-08-29 14:45:33.449
Resolved: 2012-05-16 09:05:48.6
Description: Currently the registry-ws eagerly loads a lot.
GET dataset/uuid eagerly loads it's owning org, which eagerly loads the endorsing node
This means if the Node changes it's (e.g.) title everything related to the node is invalidated for caching purposes.
I propose that we stop eagerly loading all primary resources (sub resources such as contacts etc are ok)
Comments?
]]>
Author: jcuadra@gbif.org
Created: 2012-05-11 18:26:46.16
Updated: 2012-05-11 18:27:44.453
I support stopping eagerly loading sub-entities at all (owning org, hosting org, endorsing node, etc)
I would also support just displaying the owning org UUID, hosting org UUID, etc.
example:
ORGANIZATION RESPONSE
----------------------
{
"key": "c361e830-181e-11da-9544-b8a03c50a862",
"title": "Louisiana State University Museum of Natural Science",
...
"endorsingNodeKey": "8618c64a-93e0-4300-b546-7249e5148ed2",
....
},
DATASET RESPONSE
----------------
{
"key": "9c4aa300-13e1-11de-b2e1-b8a03c50a862",
"title": "Herbarium of the Department of Natural Forests (Forest Research Institute) - Lichens",
...
"owningOrganizationKey": "63c6de50-9274-11da-8901-b8a03c50a862",
"hostingOrganizationKey": "63c6de50-9274-11da-8901-b8a03c50a862",
...
}
this will make cache flushing cleanier, and it wont impact the admin console at all as we can keep the "endorsingNodeKey" attr on the WritableOrganization (I map the admin forms to these "key" writable attributes)
Author: mdoering@gbif.org
Comment: If we do this, is there still a need for having separate readable objects or can we live with the writable versions only? That would make our code much simpler
Created: 2012-05-12 14:19:08.22
Updated: 2012-05-12 14:19:08.22
Author: trobertson@gbif.org
Created: 2012-05-12 19:40:28.43
Updated: 2012-05-12 19:40:28.43
Dataset would still have 2 representations, as it has all the metadata profile in the enriched version, which the others would only have 1 representation. I'm inclined to suggest we keep dataset with 2 representations named readable and writable, but stop eagerly loading the owning and hosting orgs. I'm also inclined to suggest we keep 2 for the others as it is quite feasible in the future that we will bring back read only metrics for things. The code complexity is nicely contained in the API (internal builders basically being the only complex bit), and the API is quite easy to understand and clean.
Author: kbraak@gbif.org
Created: 2012-05-14 11:18:40.753
Updated: 2012-05-14 11:18:40.753
Node updates are quite rare - I have asked Anne Mette for a ballpark estimate since she is doing Nodes updates but she's only back next week from vacation.
As for Organization updates, Andrea and I might do 1-2 a week tops.
I agree that invalidating the cache on such updates would be far-reaching, but they would be seldom.
In any case, I have no problem to stop eagerly loading all primary resources.
Author: kbraak@gbif.org
Created: 2012-05-21 15:16:53.937
Updated: 2012-05-21 15:16:53.937
Just to follow up with information about how often Nodes info gets updated by Anne Mette:
On average there are 2-4 changes/additions per month for the Nodes.
On top of that, there are also changes to the official delegations. That would be the same; around 2-4 changes per month.