Changes between Version 17 and Version 18 of BluePrintRegionsAndIncidents


Ignore:
Timestamp:
02/19/11 21:01:24 (11 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintRegionsAndIncidents

    v17 v18  
    118118We may want one more item of data to support invalidating results if a region changes, as follows:
    119119
    120 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.
     120It'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.
     121
     122If 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.
     123
     124One 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.
     125
     126To maintain the region's last-changed timestamp, we need to know when the location it points to is changed in a way that materially affects the geographic area it represents (boundary, lon / lat, address (?), hierarchy parent, group members.  That requires at least on database operation.  If a location that belongs to a location group is changed, that might require chaining back to find the region.  (The region's timestamp would also be changed if its location were replaced by another, but in that case, we already have the region's id.)
    121127
    122128For per-region timestamps, change the BNF thusly: