Problem
Currently, site ids are mutable; they are different every time an address data integration is performed (e.g., currently monthly). If an application makes a geocoder request, hangs on to the site id for dayw or weeks, then uses the id in another geocoder api request such sites/{siteID}/subsites, the id will likely be invalid by then. This problem will become more apparent if and when we start more frequent data integrations.
Proposed solution
Make site ids immutable. The simplest way to do this is to keep a permanent table of site ids by fullAddress. Each data integration, look up a fullAddress to see if there is already an id for it. If no id is found, create a new id and add a entry to the table for next time. Can also keep track of the date the site id was created and the last time it was used in a new data integration.
Problem Currently, site ids are mutable; they are different every time an address data integration is performed (e.g., currently monthly). If an application makes a geocoder request, hangs on to the site id for dayw or weeks, then uses the id in another geocoder api request such sites/{siteID}/subsites, the id will likely be invalid by then. This problem will become more apparent if and when we start more frequent data integrations.
Proposed solution Make site ids immutable. The simplest way to do this is to keep a permanent table of site ids by fullAddress. Each data integration, look up a fullAddress to see if there is already an id for it. If no id is found, create a new id and add a entry to the table for next time. Can also keep track of the date the site id was created and the last time it was used in a new data integration.