Changes between Version 12 and Version 13 of BluePrintRegionsAndIncidents

02/18/11 09:03:21 (13 years ago)
Pat Tressel



  • BluePrintRegionsAndIncidents

    v12 v13  
    9292We may also want to cache the gis_config currently in effect in the session in any case, not just if it was a region gis_config selected from the menu.
     94==== Detail on caching region membership ====
     96(Fran asked how this would be implemented...)
     98The proposed implementation of cached region membership is similar to the "materialized path" path currently in locations, in that it encodes the list of regions that a location has been checked against, and the result of each test, in a string.  The difference is that the region membership test can return true or false, and we need to record both -- we need to know that the location was tested against a region, not merely which region tests were true, else we'd re-do the test for regions the location is not in.  The format of the string is (in pseudo-BNF):
     101true := "T"
     102false := "F"
     103null := <empty field>
     104result := true|false
     105region_id := <id in gis_location of a region location>
     106region_result := region_id","result
     107region_result_cache := null|region_result["|"region_result]
     110That is, it looks like:
     116We may want one more item of data to support invalidating results if a region changes, as follows:
     118It's easy to invalidate the cached region membership if a location is changed (in a way that affects what actual location it points to) -- just clear it.  If the region definition changes, there is the same issue as changing the hierarchy causes for cached paths -- we would like to avoid having to go through the locations cleaning out the result for that region.  But since region (or hierarchy) changes are not going to be frequent, this may not be too much overhead.  One way of avoiding it is to add a timestamp to the region cache giving the last time it was updated, or to each test individually.  Then if we find a region has changed after the timestamp, we don't believe the cached result.  If we have only a timestamp for the cache as a whole, we clear it.  If we have individual timestamps, we just replace the result for the re-tested region.
     120For per-region timestamps, change the BNF thusly:
     123timestamp := <datetime string>
     124region_result := region_id","result","timestamp
     127Current intent is to include the timestamp in each result, to avoid the region change issue.
    94129=== Incident discussion ===
    96 This is open for ideas -- please add suggestions here.
     131Open for ideas -- please add suggestions here!
    98133An incident involves: