Changes between Version 12 and Version 13 of BluePrintRegionsAndIncidents

Timestamp:

02/18/11 09:03:21 (14 years ago)

Author:

Pat Tressel

Comment:

--

BluePrintRegionsAndIncidents

@@ -92 +92 @@
 We 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.
 
+==== Detail on caching region membership ====
+
+(Fran asked how this would be implemented...)
+
+The 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):
+
+{{{
+true := "T"
+false := "F"
+null := <empty field>
+result := true|false
+region_id := <id in gis_location of a region location>
+region_result := region_id","result
+region_result_cache := null|region_result["|"region_result]
+}}}
+
+That is, it looks like:
+
+{{{
+5,T|3,F
+}}}
+
+We may want one more item of data to support invalidating results if a region changes, as follows:
+
+It'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.
+
+For per-region timestamps, change the BNF thusly:
+
+{{{
+timestamp := <datetime string>
+region_result := region_id","result","timestamp
+}}}
+
+Current intent is to include the timestamp in each result, to avoid the region change issue.
+
 === Incident discussion ===
 
-This is open for ideas -- please add suggestions here.
+Open for ideas -- please add suggestions here!
 
 An incident involves: