everbeek
commented
9 years ago Thinking about whether I can move the node cap check to be before individual node fetches (as seen in a mapping expansion) rather than having it occur when they are being parsed to add them to the graph. It would save REST calls, but it would also probably lead to great code complexity; I would need a queue of possible callbacks to call, to allow failed ones to be replaced. For example, if the user chooses to allow 20 more nodes to be added, and the first 7 are private or invalid, I would want to try to fulfill those 7 slots with whatever else is available. This would require that the REST callbacks themselves be queued up, rather than checking when their callbacks occur (checking at a time when we can see if the node was valid).
The FetchOneConceptCallback and SearchOneConceptCallback appear to be the ones that don't actually cap check before REST call. ConceptParentRelationsCallback and ConceptChildrenRelationsCallback both get the list of nodes to expand, then checks the cap for the set of items it could expand. Those two actually have the node data at that point, so it's the relational data than really gets deferred by the cap check. It's probably fine to leave that, since the user will surely want at least one node expanded, and getting one costs as much as getting them all, in a way.
Checking all the FetchOne callbacks to see if they can be checked in advance like the relational properties on the Parents and Children callbacks.
This has been a bit of a hassle. I am closer to success. I didn't need to check for node errors in the cap check before, but now I believe I do. I noticed that when I added CORS, I disrupted the retrying behavior used for 500 errors...but now I only get persistent ones. I am thinking about shortening the time between retries for 500, and of course getting it working with CORS again.
the node cap dialog seems to take a long time to come up even for low numbers of added nodes. Why? (likely because it has to wait for REST calls to resolve in order to check. See comment further down for more...)[fixed]676 node expansion dialog cap slowed down, seemed to freeze browser. Why? (likely the 676+ REST calls! See comment further down on checking the cap prior to REST call dispatch...)[fixed]for the node cap...text saying how many to add should be hidden until it is greater than 20...that isn't the solution though. It is as though I need a progress indicator for the count (the 17). and to rephrase it to be: Add up to x nodes 20 of 17 [progress meter] available.[improved]the cap dialog appeared to not close after responding to it to add 20, when there were many more left[fixed]