ericvaandering
commented
10 years ago Comment by wildish on Fri May 27 11:55:51 2011
Here's a concrete proposal:
- we add a 'Re-evaluate request' checkbox to the request form which lets the user tell us new data is expected in the future. (let's call the opposite of a re-evaluated request a 'snapshot' request)
- re-evaluate requests only if that flag is set, wether wildcards are specified or not.
- update the updateRequest and Subscribe APIs to manipulate that flag,
- update RequestAllocator to stop re-evaluating non-wildcard requests once all data-items have been matched
-
requests with a start-time in the future would automatically have their re-evaluate flag set
then we can:
- explicitly reject a request for (re-evaluate+static) at creation-time (*)
- all other combinations (re-evaluate+growing), (snapshot+static), (snapshot+growing) make sense, and can be permitted
- explicitly test each line of the data-items for matching data only for snapshot requests, and tell the user if they are asking for stuff that is not in TMDB at that time
- reject creation of the request if any non-matching data-item is found in a snapshot request
- this would apply equally to wildcarded and non-wildcarded data-items
the re-evaluate/snapshot flag will default to snapshot. This changes the behaviour for wildcarded requests, but is a safer default in the event of typos etc.
Original Savannah ticket 82689 reported by wildish on Fri May 27 05:25:29 2011.
if a user requests several items of data, with no wildcards specified, the request will be evaluated once only.
If the request contains some items that exist already, and some that will come into existence later on, the latter will not be transferred, because the request is not re-evaluated.
The preview button could be used to check for this, and alert the user accordingly.
A similar check should be implemented in the request approval page, where the details of the request are given, much like the creation-preview.