Veidi rohkem kui aasta tagasi kirjutasin postituse selle kohta, kuidas kasutada WP_Meta_Query’t, kui teil on võtmete komplekt, mida soovite kasutada teabe andmebaasist väljavõtmiseks.
Mis saab aga juhul, kui teil on palju erinevaid võtmeid, mille tulemuseks oleks WP_Meta_Query klassi jaoks väga pikk massiiv? Näiteks mis siis, kui peaksite enne päringu seadistamist andmekogu läbi vaatama?
Mingil tasandil võib tunduda, et loomulik asi, mida teha, oleks:
- korrata võtmete kogumist,
- dünaamiliselt luua tulemusi,
- ühendage need üheks tulemuste komplektiks,
- siis tööta sellega, mis sulle antakse.
Kuid kas see ei tundu pisut tülikas (rääkimata aeglasest)?
Mis puutub WordPressi API kasutamiseks, siis ma teen kõik endast oleneva, et sellest kinni pidada enne, kui räägin näiteks otse andmebaasiga, kuid mõnikord on mõttekas kirjutada toorpäring, mitte kirjutada lihtsalt mingit nutikat koodi. WordPressi API tööle panemiseks.
Enne kui hakkan arutama, miks ma olen teinud asju, mis mul on, tahan selgitada probleemi ja lähenemisviisi. See päästab tõenäoliselt kedagi enneaegselt kommentaaridesse hüppamast.
Sellel ekraanipildil pole päringuga midagi pistmist. Lõbu pärast vaid pilt IDE-st.
Nii et siin:
- Mul on standardne väärtuste massiiv, mida lõpuks kasutatakse metaandmete võtmiseks ja nende põhjal kohandatud postitustüübi loomiseks (kuna need on imporditud kolmanda osapoole allikast).
- Olen päringute parameetrite muutmise (ja seega ka ettevalmistamise kasutamise) suur pooldaja, et tagada andmete õige päringute tegemine andmebaasist. Kahjuks seda päringu sooritamisel ei juhtunud. Selgitan hiljem selles postituses, miks.
- Seega, võtke massiiv ja selle stringiks teisendamine on kasulik, kuid see ei lahenda ikkagi probleemi, miks standardne ettevalmistusfunktsioon ei töötanud.
Seda öeldes selgitan ma mõnda asja:
- miks ma otsustasin metaandmete väärtuste salvestamiseks kasutada massiivi,
- miks ma kasutasin implode’i nende stringiks teisendamiseks,
- miks ma ei kasuta päringu käsitlemiseks ettevalmistust .
Metaandmete väärtuste kohta
Põhjus, miks metaandmeid massiivis klassi omadusena hoitakse, on see, et see massiiv võib aja jooksul muutuda.
See tähendab, et meil võib olla vaja importida täiendavaid kolmandate osapoolte andmeid, eemaldada kolmanda osapoole andmed või meil võib tekkida vajadus teha olemasolevates muudatusi.
Kui neid andmeid hoitakse ühes kohas, muudab see koodi tulevaste versioonide haldamise palju lihtsamaks.
Massiivi imploding
Kui käivitate andmebaasi päringu ja peate töötama andmemassiiviga, saate kasutada WP_Meta_Query ja kasutada iga võtit argumentide massiivi osana.
Aga kui teil on suhteliselt suur andmekogum, peate kõigepealt need kõik läbi vaatama, seejärel looma päringu ja seejärel töötlema.
Ja kui olete kõik selle teinud, pole ma veendunud, et kirjutatud kood pole jõudluse arvelt tulnud. Seetõttu otsustan mõnikord kasutada wpdb -d .
Prepare’i ei kasutata
Nüüd proovin andmebaasiga otse liidestades veenduda, et:
- Mul on selleks hea põhjus,
- Kasutan parameetritega päringuid.
Kuid olen selle konkreetse andmekogumiga mõnda aega töötanud, püüdes kasutada kõiki WordPressi arenduse permutatsioone, millest olen teadlik (sealhulgas rääkinud sellest mitme eakaaslasega), et see parimal võimalikul viisil toimiks.
Seda siiski ei juhtunud. Ja just siis sattusin ma Codexi järgmisele lehele :
99% juhtudest võite selle asemel kasutada $wpdb->prepare() ja see on soovitatav meetod. See funktsioon on mõeldud kasutamiseks ainult neil harvadel juhtudel, kui te ei saa lihtsalt kasutada $wpdb->prepare(). Üks näide on massiivi ettevalmistamine kasutamiseks IN-klauslis.
Ja täpselt seda ma teha püüdsin: otsisin postituse metatabelist, kus metavõtme väärtused sisaldusid massiivis.
Nii et siin on, kuidas ma selle kõik välja töötasin.
Esiteks lõin massiivi erinevate metavõtmete hoidmiseks, mida ma tean, et pean lõpuks kaardistama (kuigi võtmete väärtus pole selle postituse jaoks oluline):
<?php
// This is used to maintain a map of data should we need to add more.
$data_types = [
'data_item_one',
'data_item_two',
'...'
'data_item_ten,
];
Seejärel teisendasin need MySQL-valmidusega stringiks. Tõsi, see ei ole kasutaja sisestus ja seda kasutatakse IN – klauslis, seega ei saa seda ettevalmistuslauses kasutada :
<?php
/**
* Converts the incoming array into a comma-delimited string with
* quotes wrapped around each key.
*
* @access private
*
* @param array $arr The array to convert to a string.
* @return string The string representation of the array delimited by quotes and commas.
*/
private function convert_to_sql_ready_string( $arr) {
return '"'. implode( $arr, '","' ). '"';
}
Lõpuks lõin päringu ja hankisin tulemused:
<?php
public function get_data_values() {
global $wpdb;
$query = "
SELECT post_id, meta_key, meta_value
FROM $wpdb->postmeta WHERE
meta_key in ($this->data_types) AND
meta_value <> '';
";
$results = $wpdb->get_results( $query );
return $results;
}
Ja nii ma töötasin massiivide, klassi atribuudiga ja seadistasin oma päringu.
Kas see on parim viis IN-klauslitega WordPressi päringutega töötamiseks? Ma pole kindel, kuid arvestades oma kogemusi, loetut ja selle toimimist, olen lõpptulemusega rahul.