Changes between Version 12 and Version 13 of BluePrintRegionsAndIncidents


Ignore:
Timestamp:
02/18/11 09:03:21 (11 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 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.
    9393
     94==== Detail on caching region membership ====
     95
     96(Fran asked how this would be implemented...)
     97
     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):
     99
     100{{{
     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]
     108}}}
     109
     110That is, it looks like:
     111
     112{{{
     1135,T|3,F
     114}}}
     115
     116We may want one more item of data to support invalidating results if a region changes, as follows:
     117
     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.
     119
     120For per-region timestamps, change the BNF thusly:
     121
     122{{{
     123timestamp := <datetime string>
     124region_result := region_id","result","timestamp
     125}}}
     126
     127Current intent is to include the timestamp in each result, to avoid the region change issue.
     128
    94129=== Incident discussion ===
    95130
    96 This is open for ideas -- please add suggestions here.
     131Open for ideas -- please add suggestions here!
    97132
    98133An incident involves: