कस्टम कैशिंग लागू करने के लिए सर्वोत्तम अभ्यास?

Question

प्रत्येक प्रकार की इकाई के प्रत्येक उदाहरण के लिए, मैं कई कैश उत्पन्न करता हूं, जिसका नाम कुछ इस प्रकार है: [module_name]__[entity_type]__[entity_id]__[string_depending_on_where_the_cache_came_from]

अब जब भी कोई इकाई अपडेट की जाती है, तो मैं संबंधित इकाई प्रकार और आईडी से शुरू होने वाले सभी कैश को छोड़ना चाहता हूं।

मुझे इन कैश को कैसे स्टोर / क्लियर करना चाहिए?

वर्तमान में मैं सिर्फ cache_set () हूं , लेकिन जब मैं स्पष्ट करना चाहता हूं तो एक समस्या प्रस्तुत करता है, क्योंकि मुझे सभी प्रासंगिक कैश के नाम नहीं पता हैं। क्या db_delete () के साथ कैश प्रविष्टियों को गिराना सुरक्षित है?

Comments

यदि आप सभी प्रासंगिक कैश के नाम नहीं जानते हैं, तो आप कैसे उपयोग कर सकते हैं db_delete()?

— kiamlaluno

Answer 1

कैश से प्रविष्टियों को हटाने के लिए, आपको cache_clear_all () का उपयोग करना चाहिए । कारण यह है कि प्रयुक्त कैश कार्यान्वयन सक्रिय डेटाबेस में डेटाबेस तालिका का उपयोग नहीं कर सकता है। ऐसा DrupalDatabaseCache वर्ग के साथ होता है , लेकिन यह हर वर्ग के लिए सही नहीं होना चाहिए।

यदि आप _cache_get_object () ( cache_get () और cache_set () द्वारा बुलाए गए फ़ंक्शन ) को देखते हैं, तो आप देखेंगे कि इसमें निम्न कोड है।

  static $cache_objects; 
  if (!isset($cache_objects[$bin])) {
    $class = variable_get('cache_class_' . $bin);
    if (!isset($class)) {
      $class = variable_get('cache_default_class', 'DrupalDatabaseCache');
    }
    $cache_objects[$bin] = new $class($bin);
  }
  return $cache_objects[$bin];

कैश कार्यान्वयन के लिए वर्ग प्रत्येक कैश बिन स्टोर के लिए अलग हो सकता है, और यहां तक ​​कि डिफ़ॉल्ट को भी बदला जा सकता है।

निजी अद्यतन स्थिति कैश सिस्टम बताता है कि क्यों सामान्य कैश फ़ंक्शंस का उपयोग _update_cache_clear () , _update_cache_get () , और _update_cache_set () में नहीं किया जाता है । (जोर मेरा है।)

हम विशेष रूप से उपलब्ध अपडेट के बारे में प्राप्त आंकड़ों को सहेजने के लिए कोर कैश एपीआई का उपयोग नहीं करते हैं। यह महत्वपूर्ण है कि इस कैश को केवल तभी साफ़ किया जाता है जब हम नए उपलब्ध अपडेट डेटा को सफलतापूर्वक लाने के बाद इसे पॉप्युलेट कर रहे हों। कोर कैश एपीआई का उपयोग सभी प्रकार की संभावित समस्याओं का परिणाम है जो हर समय उपलब्ध अपडेट डेटा प्राप्त करने का प्रयास करेंगे, जिसमें यह भी शामिल होगा कि क्या किसी साइट का "न्यूनतम कैश जीवनकाल" है (जो कि न्यूनतम और अधिकतम दोनों है), परिभाषित या यदि कोई साइट मेम्चे या किसी अन्य प्लग-वे कैश सिस्टम का उपयोग करती है जो अस्थिर कैश को मानता है।

अद्यतन प्रबंधक मॉड्यूल अभी भी {cache_update} तालिका का उपयोग करता है, लेकिन के बजाय का उपयोग कर cache_set(), cache_get()और cache_clear_all(), निजी सहायक कार्यों है कि इन समान आधारभूत कार्यों को लागू लेकिन सुनिश्चित करें कि कैश समय से पहले ही मंजूरी दे दी नहीं है देखते हैं, और डेटा हमेशा में संग्रहीत किया जाता है कि डेटाबेस, भले ही मेमकाचे या एक अन्य कैश बैकेंड उपयोग में हो।

अपडेट प्रबंधक की विशिष्ट आवश्यकताएं हैं जो आवश्यक हैं क्योंकि अपडेट जानकारी प्राप्त करने का प्रयास अक्सर Drupal.org सर्वर के साथ समस्याएँ पैदा करता है, यह देखते हुए कि अपडेट प्रबंधक संभावित रूप से ड्रुपल चलाने वाली किसी भी साइट से अपडेट जानकारी प्राप्त कर सकता है।

आपके मामले में, आप [module_name]__[entity_type]__[entity_id]__[string_depending_on_where_the_cache_came_from]एक कैश बिन स्टोर के लिए कैश आईडी के रूप में उपयोग कर सकते हैं । यदि आपको किसी इकाई के लिए सभी प्रविष्टियों को हटाने की आवश्यकता है, तो आप निम्नलिखित कोड का उपयोग कर सकते हैं।

cache_clear_all("{$module}__{$entity_type}__{$entity_id}__", $bin, TRUE);

यदि आप $moduleकैश साफ़ करते समय असाइन करने के लिए मान प्राप्त नहीं कर सकते हैं, या आप उस मॉड्यूल से स्वतंत्र रूप से कैश प्रविष्टि को हटाना चाहते हैं जिसके लिए डेटा कैश किया गया है, तो आप एक अलग कैश आईडी, जैसे [entity_type]__[entity_id]__[string_depending_on_where_the_cache_came_from], या का उपयोग कर सकते हैं [entity_type]__[entity_id]__[module_name]__[string_depending_on_where_the_cache_came_from]। cache_clear_all()कैश आईडी के साथ सभी कैश प्रविष्टियों को हटाता है, स्ट्रिंग के साथ शुरू होने वाले तर्क के रूप में पारित हो गया $wildcardहै TRUE, और कैश आईडी नहीं है '*'। इस स्थिति में, निम्न कोड के साथ कैश साफ़ हो जाएगा।

cache_clear_all("{$entity_type}__{$entity_id}__", $bin, TRUE);

Answer 2

मैं एक अच्छे कारण के बारे में नहीं सोच सकता हूं कि प्रविष्टियों को मैन्युअल रूप से छोड़ने के कारण समस्या क्यों होगी। बेशक, यह मानता है कि आप MySQL को अपने विशेष कैश के बैकएंड के रूप में उपयोग कर रहे हैं; हालाँकि मुझे लगता है कि कैश बैक के किसी अन्य प्रकार पर भी यही लागू होता है, लेकिन यह स्पष्ट करने का तरीका डेटाबेस क्वेरी नहीं होगा।

यदि आप कोर अपडेट मॉड्यूल को एक उदाहरण के रूप में लेते हैं, तो यह cache_*फ़ंक्शन को बायपास करता है और अपने कैश को मैन्युअल रूप से साफ़ करता है:

function _update_cache_clear($cid = NULL, $wildcard = FALSE) {
  if (empty($cid)) {
    db_delete('cache_update')
      // Clear everything except fetch task information because these are used
      // to ensure that the fetch task queue items are not added multiple times.
      ->condition('cid', 'fetch_task::%', 'NOT LIKE')
      ->execute();
  }
  else {
    $query = db_delete('cache_update');
    if ($wildcard) {
      $query->condition('cid', $cid . '%', 'LIKE');
    }
    else {
      $query->condition('cid', $cid);
    }
    $query->execute();
  }
}

मुझे हमेशा लगता है "अगर यह कोर के लिए पर्याप्त है, तो यह मेरे लिए काफी अच्छा है" :)