Query al database per aggiornare rapidamente i dati, parte 2
Questa è la seconda e ultima parte di una serie sulle query dirette al database, come suggerisce il titolo. In particolare, si tratta di modificare lo stato dei post (ma è rilevante per più di questo).
Foto di Ross Findon su Unsplash
Questo è un altro post che sarà un’illustrazione di come utilizzare $ wpdb per aggiornare rapidamente le informazioni in base ai metadati.
E il codice fornito in quel post funziona, ma se stai cercando di renderlo più orientato agli oggetti, allora c’è più lavoro che può essere fatto.
Prima di passare al post vero e proprio, tuttavia, è importante notare che quando si tratta di programmazione orientata agli oggetti, c’è molto lavoro che può essere svolto nella progettazione della classe e nella creazione di livelli di astrazione.
Ad un certo punto, devi tracciare il proverbiale confine tra quando utilizzerai le interfacce, quanto saranno granulari le tue classi in termini di ciò che stanno astraendo e simili.
E lo scopo di questo post è aiutare a fornire un migliore design orientato agli oggetti, ma non è un esercizio renderlo il più ottimale possibile. Discuto argomenti come questo in un’altra serie di post.
Ma tienilo a mente quando leggi il codice per tutto il resto del post.
Query al database per aggiornare rapidamente i dati, parte 2
Dato dove ci siamo lasciati, abbiamo una singola funzione che fa le seguenti cose:
- recuperare tutti i post associati a una specifica meta chiave,
- determinare se dobbiamo uscire presto,
- aggiornare lo stato del post di eventuali post esistenti.
La prima cosa da notare è che una singola funzione è eccessiva, quindi deve essere suddivisa in diverse altre funzioni. E poiché è orientato agli oggetti, dobbiamo assicurarci che qualsiasi cosa stia facendo una funzione non sia necessariamente basata su passaggi precedenti: è esattamente di questo che si tratta la programmazione procedurale.
Utilizzeremo invece questa opportunità per impostare le funzioni, in modo che operino su qualsiasi dato venga loro passato, indipendentemente da come sono arrivate.
Infine, spetta a te, come sviluppatore, determinare se desideri avere una singola classe per fare questo, più di una classe, o avere un insieme di classi correlate che ereditano da una classe genitore.
Ancora una volta, è tutto su quanto astratto vuoi rendere il codice.
Per ora, però, andiamo avanti con la rottura delle cose.
1 Prendi gli ID Post con la Meta Key associata
Proprio come nel primo post, vogliamo assicurarci di recuperare gli ID post correlati a una meta chiave specifica.
Per rendere questa funzione il più flessibile possibile, la configureremo su:
- accetta la meta chiave come una stringa,
- restituire una matrice
La funzione sarà quindi simile a questa:
<?php
/**
* Locates all of the post IDs that are associated with an empty meta key (which
* is specified as an argument for the function).
*
* @param string $metaKey The meta key used to retrieve the set of post IDs.
* @return array $results The set of product IDs associated with the specified meta key.
*/
public function getInactivePostIds(string $metaKey): array
{
global $wpdb;
$results = $wpdb->get_results(
$wpdb->prepare(
"
SELECT post_id
FROM $wpdb->postmeta
WHERE meta_key = %s
AND meta_value = ''
",
$metaKey) );
return $results;
}Nel primo post, abbiamo suddiviso questo in tre passaggi (che sono anche descritti sopra). Qui, tuttavia, possiamo combinare il secondo e il terzo passaggio in un’unica funzione.
2 Aggiorna lo stato del post
Come ho già detto, l’unico aspetto della programmazione orientata agli oggetti è assicurarsi che le funzioni che stiamo utilizzando siano indipendenti da come sono stati generati i dati che stanno ricevendo.
Al contrario, hanno un unico algoritmo da eseguire per concentrarsi sui dati passati nella funzione. In questo caso, vogliamo prendere la serie di risultati, che sono ID post, e aggiornare lo stato del post in modo che sia impostato su bozza.
Ciò significa che la funzione accetterà un array ma non restituirà nulla. Potenzialmente, potresti tenere traccia di molti post che ha aggiornato (o se ha aggiornato qualcosa), ma mi concentro solo sul refactoring del codice che già abbiamo.
Quindi è quello che faremo. E la prima cosa è assicurarsi che ci siano dati effettivi con cui lavorare. In tal caso, scorrere l’array elenco di ID post e modificare lo stato del post:
<?php
/**
* Updates incoming posts by setting their post status to 'draft.'
*
* @param array $postData the set of post IDs associated with the specific meta key.
*/
public function setPostsToDraft(array $postData)
{
// If the post data is empty, there's nothing to do.
if (0 === count($postData)) {
return;
}
// Otherwise, set the post_status of the specified post IDs to 'draft'.
global $wpdb;
foreach ($postData as $post) {
$wpdb->get_results(
$wpdb->prepare(
"
UPDATE $wpdb->posts
SET post_status = %s
WHERE ID = %d
",
'draft',
(int) ($post->post_id)) );
}
}Puoi vedere che non è molto diverso dal lavoro svolto nel primo post, ma ora solleva alcune domande.
3 Considerazioni orientate agli oggetti
Quando si lavora con codice come questo:
- Appartiene tutti alla stessa classe oa classi separate?
- Dovrebbe esserci una classe base e, se sì, perché o perché no?
- Dovrebbe esserci una singola funzione pubblica invocata che chiama questi metodi (e li ha contrassegnati come privati)?
- Dobbiamo lasciare pubbliche le funzioni?
Per questo post, farò quanto segue:
- Esponi ogni funzione come metodo pubblico. Questo è così che se ci sono dati restituiti dal primo metodo, potresti potenzialmente fare qualcos’altro con esso.
- Tienilo contenuto in un’unica classe. In questo modo, possiamo creare un’istanza di una singola classe e quindi usarla per fare qualsiasi lavoro dobbiamo fare. Se ci fossero altri metodi, useremmo quegli stessi metodi.
- Inizia con l’interfaccia. Non mi preoccuperò di scrivere un’interfaccia solo per mostrare un’interfaccia (presumo sia abbastanza facile da dedurre date le funzioni che abbiamo in questo momento), ma prenderò la classe e mostrerò come possiamo invocare il funzioni “dall’esterno verso l’interno".
Quindi inizierò con l’ultimo punto e lavorerò a ritroso. Ecco un modo per lavorare con il codice:
<?php
$postStatusModifier = new PostStatusModifier();
$inactivePost = $postStatusModifier->getInactivePostIds('acme-status');
$postStatusModifier->setPostsToDraft($inactivePosts);E poi ecco come appare l’intera classe :
<?php
class PostStatusModifier
{
/**
* Locates all of the post IDs that are associated with an empty meta key (which
* is specified as an argument for the function).
*
* @param string $metaKey The meta key used to retrieve the set of post IDs.
* @return array $results The set of product IDs associated with the specified meta key.
*/
public function getInactivePostIds(string $metaKey): array
{
global $wpdb;
$results = $wpdb->get_results(
$wpdb->prepare(
"
SELECT post_id
FROM $wpdb->postmeta
WHERE meta_key = %s
AND meta_value = ''
",
$metaKey) );
return $results;
}
/**
* Updates incoming posts by setting their post status to 'draft.'
*
* @param array $postData the set of post IDs associated with the specific meta key.
*/
public function setPostsToDraft(array $postData)
{
// If the post data is empty, there's nothing to do.
if (0 === count($postData)) {
return;
}
// Otherwise, set the post_status of the specified post IDs to 'draft'.
global $wpdb;
foreach ($postData as $post) {
$wpdb->get_results(
$wpdb->prepare(
"
UPDATE $wpdb->posts
SET post_status = %s
WHERE ID = %d
",
'draft',
(int) ($post->post_id)) );
}
}
}In generale, servirà agli stessi scopi del primo ma in un modo più orientato agli oggetti.
Non è così
Come ho provato a ripetere più volte in questo post, questo non è il modo definitivo per fare questo lavoro. Invece, è un modo in cui il lavoro può essere svolto.
Puoi riprogettare, rifattorizzare o riutilizzarlo come meglio credi. Lo scopo, tuttavia, è mostrare come disaccoppiare la logica che normalmente vediamo come procedurale in qualcosa che è un po’ meno dipendente da se stesso e lascia spazio a un lavoro aggiuntivo.