Hieman yli vuosi sitten kirjoitin viestin WP_Meta_Queryn käyttämisestä aina, kun sinulla on avaimia, joita haluat käyttää tietojen hakemiseen tietokannasta.
Entä jos sinulla on useita erilaisia avaimia, jotka johtaisivat todella pitkän taulukon luomiseen WP_Meta_Query- luokassa? Entä jos sinun pitäisi esimerkiksi käydä läpi tietokokoelma ennen kyselyn määrittämistä?
Jollain tasolla saattaa tuntua, että luonnollinen asia olisi:
- iteroida läpi avainkokoelman,
- rakentaa tuloksia dynaamisesti,
- yhdistä ne yhdeksi tulossarjaksi,
- sitten työskentele sen kanssa, mitä sinulle annetaan.
Mutta eikö se kuulosta hieman hankalalta (puhumattakaan hitaalta)?
Mitä tulee WordPress API:n käyttöön, teen kaikkeni pysyäkseni siinä ennen kuin puhun esimerkiksi suoraan tietokantaan, mutta joskus on myös järkevää kirjoittaa raakakysely kuin kirjoittaa jonkinlainen älykäs koodi. jotta WordPress API toimisi.
Ennen kuin aloitan perustelut sille, miksi olen tehnyt asioita, jotka minulla on, haluan selittää ongelman ja lähestymistavan. Tämä todennäköisesti säästää jonkun hyppäämästä kommentteihin ennenaikaisesti.
Tällä kuvakaappauksella ei ole mitään tekemistä kyselyn kanssa. Vain kuva IDE:stä huvin vuoksi.
Joten tässä:
- Minulla on vakioarvoja, joita käytetään lopulta metatietojen ottamiseen ja mukautetun viestityypin luomiseen niistä (koska ne on tuotu kolmannen osapuolen lähteestä).
- Olen suuri kannattaja kyselyiden parametroinnissa (ja siten valmistelun käyttämisessä) varmistaakseni, että tiedot ovat oikein kyselyitä tietokantaa vastaan. Valitettavasti näin ei tapahtunut, kun yritettiin suorittaa tätä kyselyä. Selitän miksi myöhemmin tässä viestissä.
- Joten ota taulukko ja sen muuntaminen merkkijonoksi on hyödyllistä, mutta se ei silti ratkaise ongelmaa, miksi tavallinen valmistelutoiminto ei toiminut.
Tämän sanottuani aion selittää muutaman asian:
- miksi päätin käyttää taulukkoa metatietoarvojen tallentamiseen,
- miksi olen käyttänyt implodea muuntamaan ne merkkijonoksi,
- miksi en käytä valmistelua kyselyn käsittelemiseen.
Metatietoarvoista
Syy metatietojen pitämiseen taulukossa luokan ominaisuutena johtuu siitä, että tämä taulukko voi muuttua ajan myötä.
Toisin sanoen saatamme joutua tuomaan lisää kolmannen osapuolen tietoja, meidän on poistettava kolmannen osapuolen tietoja tai meidän on ehkä tehtävä joitain muutoksia olemassa oleviin tietoihin.
Kun nämä tiedot säilytetään yhdessä paikassa, koodin tulevien versioiden hallinta on paljon helpompaa.
Imploding The Array
Aina kun suoritat kyselyä tietokantaa vastaan ja sinun on työskenneltävä datajoukon kanssa, voit käyttää WP_Meta_Queryä ja käyttää jokaista avainta argumenttitaulukon osana.
Mutta jos sinulla on suhteellisen suuri joukko tietoja, sinun täytyy ensin käydä läpi kaikki, sitten sinun on luotava kysely ja sitten sinun on käsiteltävä se.
Ja kun olet tehnyt kaiken tämän, en ole vakuuttunut siitä, että kirjoitettu koodi ei ole tapahtunut suorituskyvyn kustannuksella. Tästä syystä päätän joskus käyttää wpdb :tä .
Ei käytä Preparea
Nyt kun olen yhteydessä suoraan tietokantaan, yritän varmistaa:
- Minulla on hyvä syy tehdä niin,
- Käytän parametroituja kyselyitä.
Mutta olen työskennellyt tämän tietyn tietojoukon kanssa jonkin aikaa yrittäessäni käyttää kaikkia WordPress-kehityksen permutaatioita, joista olen tietoinen (mukaan lukien useiden kollegoiden kanssa puhuminen siitä), jotta tämä toimisi parhaalla mahdollisella tavalla.
Se ei kuitenkaan tapahtunut. Ja silloin törmäsin seuraavaan Codexin sivuun :
99 %:ssa tapauksista voit käyttää sen sijaan $wpdb->prepare():tä, ja se on suositeltava tapa. Tämä toiminto on tarkoitettu käytettäväksi vain niissä harvoissa tapauksissa, joissa et voi helposti käyttää $wpdb->prepare() -toimintoa. Yksi esimerkki on taulukon valmisteleminen käytettäväksi IN-lauseessa.
Ja juuri sitä yritin tehdä: Etsin post-metataulukosta, jossa meta-avainarvot sisältyivät taulukkoon.
Joten tässä on, kuinka selvitin tämän kaiken.
Ensin loin taulukon eri meta-avainten säilyttämiseksi, jotka minun on lopulta kartoitettava (vaikka avainten arvolla ei ole väliä tämän viestin kannalta):
<?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,
];
Sitten muunsin ne MySQL-valmiiksi merkkijonoiksi. Myönnetään, että tämä ei ole käyttäjän syöte, ja sitä käytetään IN – lauseessa, joten sitä ei voi käyttää valmistelulauseessa :
<?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, '","' ). '"';
}
Lopulta loin kyselyn ja hain tulokset:
<?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 näin päädyin työskentelemään taulukoiden, luokkaominaisuuden kanssa ja määrittämään kyselyni.
Onko tämä paras tapa työskennellä WordPress-kyselyjen kanssa IN-lausekkeilla? En ole varma, mutta kokemukseni, lukemani ja sen toimivuuden perusteella olen tyytyväinen lopputulokseen.