Perché WordPress sceglie la serializzazione dei dati su json_encode?

Nella mia piccola età con WordPress, ho visto WordPress stesso e i suoi plugin amichevoli utilizzano PHP serialize()per archiviare i dati in db in molti casi. Ma in una recente ricerca ho trovato un serio supporto da parte della community per gli json_encode()over serialize().

• Un test che dimostra json_encode()è meglio di serialize()- StackOverflow
• Ragioni per cui json_encode()può essere utilizzato e perché no: StackOverflow

E ho testato personalmente un array associativo con entrambi, che mostra:

• serialize() immagazzina 342 caratteri
• json_encode() memorizza 285 caratteri

Perché lo sto chiedendo?

Sono su un progetto mentre sto per memorizzare i metacampi ricorrenti in un post. Dove:

• I dati sarebbero sostanzialmente in inglese, ma a volte possono essere bengalesi
• I dati sarebbero array associativo, profondo 3 livelli (spero di aver compreso correttamente i livelli ):

array(
    1 => array(
        'key'=>'value',
        'key2'=>'value'
    ),
    2 => array(
        'key'=>'value',
        'key2'=>'value'
    )
)

Ho controllato che il campo postmetadella tabella meta_valuesia un longtext, ciò significa una lunghezza di 4.294.967.295 caratteri (4 GB).

Quindi ho bisogno di una soluzione solida per conservare le cose.

Penso, non sicuro al 100% che questa fosse la vera ragione per cui gli sviluppatori del WP hanno adottato questo approccio, ma il buon senso mi dice che serializzare preserva i tipi di variabili e ha un mini rilevamento degli errori incorporato, e json memorizza solo valori di stringa { key : value }, quindi quando per tornare a PHP dovrai indovinare il formato o crearne uno. Questo ti costringerà ad avere due modi diversi di gestire i tuoi dati: precedente, per archiviarli come json e dopo aver decodificato il json tornerà come un oggetto totalmente diverso.

Questo è il motivo principale per cui la differenza di dimensioni, PHP sta memorizzando non solo un array; sta memorizzando quanti elementi c'erano nell'array quando è stato serializzato, i loro tipi e i loro valori.

Non si memorizzano solo coppie di valori-chiave nel database, ma si può anche archiviare un oggetto con tipi di variabili differenti.

La codifica JSON è stata introdotta in PHP 5.2, WordPress è molto più vecchia ed è nata (e progettata per) PHP 4.

La serializzazione dei dati è una cosa pervasiva in WordPress, quindi passare dalla serializzazione PHP alla codifica JSON significherebbe un enorme problema di compatibilità con le versioni precedenti e, se conosco un po 'WordPress, ciò non accadrà mai.

Detto questo, se pensi che la codifica JSON sia migliore per te della serializzazione PHP, basta usarla.

Se passi una stringa (che è la versione codificata JSON dei tuoi dati) per pubblicare meta-funzioni WordPress non la toccherà, ma dovrai ricordare di decodificare i dati JSON al momento del recupero.

Se la dimensione dello spazio di archiviazione del DB è molto importante per te, probabilmente ne vale la pena il lavoro aggiuntivo, altrimenti lascia che WordPress usi ciò che usa e non ti interessa.

Forse, puoi valutare se è il caso di tabelle personalizzate per salvare i tuoi dati.

Sono tentato di chiudere questo come "soggetto a opinione", ma penso che ci siano un paio di buone risposte alla domanda. Ho intenzione di andare con "storia".

1) json_encodeè relativamente nuovo nel core di PHP.

json_encode

(PHP 5> = 5.2.0, PECL json> = 1.2.0) json_encode - Restituisce la rappresentazione JSON di un valore

http://php.net/manual/en/function.json-encode.php

json_encodenon sarebbe stato affidabile ai primi tempi di WordPress. È stato implementato in PHP "core" solo in 5.2, sebbene fosse disponibile come estensione PECL molto prima.

In secondo luogo, se si alimenta un oggetto come un WP_Queryoggetto, json_encodesi ottiene un stdClassoggetto json_decode. serialize/ unserializeconserverà l'oggetto.