Answers.Body: <p>The answer is bug, but not for the reasons I thought.</p>
  
  <p>In short: the addition of MagicMerge seems to be the culprit, resulting in changed behavior when geocodeMethod is set to NULL.</p>
  
  <p>Long answer:</p>
  
  <p>First, setting the property of a singleton in one function, does result in it persisting even in other functions. The singleton really does act like a global variable. That's how this has worked all the way up to 4.7.</p>
  
  <p>However, in 4.7 <a href="https://issues.civicrm.org/jira/browse/CRM-16373" rel="nofollow noreferrer">MagicMerge was introduced</a> to streamline the configuration object.</p>
  
  <p>This approach added __get and __set functions to handle properties that are not defined.</p>
  
  <p>Now, if a property (like geocodeMethod) is set, it is added to the cache (<code>$this-&gt;cache[$name] = $v;</code>). So far so good.</p>
  
  <p>However, when it is retrieved, it only comes from the cache if it is set:</p>
  
  <pre><code>if (isset($this-&gt;cache[$k])) {
    return $this-&gt;cache[$k];
  }
  </code></pre>
  
  <p>Oops. If we set it to NULL it will never be retrieved from the cache and will always be retrieved using the function <code>CRM_Utils_Geocode::getProviderClass</code></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-04-18T17:16:17.070Z
Answers.Text: I've opened (and submitted a patch for) an upstream bug: https://issues.civicrm.org/jira/browse/CRM-20381
Answers.UserDisplayName: Jamie
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-04-04T14:49:51.960Z
Answers.LastActivityDate: 2017-04-04T14:49:51.960Z
Answers.UserDisplayName: Jamie
Body: <p>I never check the geocode box when importing. Yet, I found that even small imports were taking a long time. I ran strace on the php process and saw lots of lookups to google. So I disabled both the mapping provider and geocoding provider globally, re-ran the import and it went through in a fraction of the time.</p>
  
  <p>Next, I took a closer look at the code that is triggered based on the geo coding checkbox:</p>
  
  <p>The file: Contact/Import/Parser/Contact.php contains:</p>
  
  <pre><code> public function import($onDuplicate, &amp;$values, $doGeocodeAddress = FALSE) {
      $config = CRM_Core_Config::singleton();
      $this-&gt;_unparsedStreetAddressContacts = array();
      if (!$doGeocodeAddress) {
        // CRM-5854, reset the geocode method to null to prevent geocoding
        $config-&gt;geocodeMethod = NULL;
      }
  </code></pre>
  
  <p>In other words, if geo code checkbox is unchecked, the $doGeocodeAddress is set to false. If it is set to false, then we set <code>$config-&gt;geocodeMethod = NULL;</code></p>
  
  <p>Hm. Could this possibly work? If you set a property on a singleton locally in a function, it seems like it would not be available outside the function.</p>
  
  <p>However, this "fix" <a href="https://issues.civicrm.org/jira/browse/CRM-5854" rel="nofollow noreferrer">has been in place for years</a> so I'm asking this question as a sanity check before opening a ticket.</p>
  
  <p>Maybe something changed in the behavior of PHP?</p>
  
Tags: <import><geocoding>
Title: all imports seem to geo code
ThreadText: # all imports seem to geo code
  
  (Asked by: username_0 on 2017-03-31)
  
  I never check the geocode box when importing. Yet, I found that even small imports were taking a long time. I ran strace on the php process and saw lots of lookups to google. So I disabled both the mapping provider and geocoding provider globally, re-ran the import and it went through in a fraction of the time.
  Next, I took a closer look at the code that is triggered based on the geo coding checkbox:
  The file: Contact/Import/Parser/Contact.php contains:
   public function import($onDuplicate, &$values, $doGeocodeAddress = FALSE) {
      $config = CRM_Core_Config::singleton();
      $this->_unparsedStreetAddressContacts = array();
      if (!$doGeocodeAddress) {
        // CRM-5854, reset the geocode method to null to prevent geocoding
        $config->geocodeMethod = NULL;
      }
  
  In other words, if geo code checkbox is unchecked, the $doGeocodeAddress is set to false. If it is set to false, then we set $config->geocodeMethod = NULL;
  Hm. Could this possibly work? If you set a property on a singleton locally in a function, it seems like it would not be available outside the function.
  However, this "fix" has been in place for years so I'm asking this question as a sanity check before opening a ticket.
  Maybe something changed in the behavior of PHP?
  
  **Tags:** import, geocoding
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-04-04. Score: 1
  
  The answer is bug, but not for the reasons I thought.
  In short: the addition of MagicMerge seems to be the culprit, resulting in changed behavior when geocodeMethod is set to NULL.
  Long answer:
  First, setting the property of a singleton in one function, does result in it persisting even in other functions. The singleton really does act like a global variable. That's how this has worked all the way up to 4.7.
  However, in 4.7 MagicMerge was introduced to streamline the configuration object.
  This approach added __get and __set functions to handle properties that are not defined.
  Now, if a property (like geocodeMethod) is set, it is added to the cache ($this->cache[$name] = $v;). So far so good.
  However, when it is retrieved, it only comes from the cache if it is set:
  if (isset($this->cache[$k])) {
    return $this->cache[$k];
  }
  
  Oops. If we set it to NULL it will never be retrieved from the cache and will always be retrieved using the function CRM_Utils_Geocode::getProviderClass
  
  > **Comments:**
  > **username_0**: I've opened (and submitted a patch for) an upstream bug: https://issues.civicrm.org/jira/browse/CRM-20381  
  
  ---
  
  