Observação: Isto foi adaptado de uma conversa que aconteceu no Slack do Make WP (consulte o link para obter mais contexto).
Nossa situação atual em relação às miniaturas
As miniaturas foram coletadas pelos provedores e inseridas na coluna thumbnail do catálogo. Agora temos dados nessa coluna, e ela não foi removida. Como essa coluna também existe na API, os dados dela (tanto para áudio quanto para imagens) também são copiados para a coluna thumbnail lá. No entanto, somente o modelo Audio usa a coluna thumbnail; o modelo Image a ignora e tenta criar uma miniatura reduzida usando a URL da imagem principal. A classe MediaStore no provedor foi modificada para que nenhuma nova URL de miniatura possa ser adicionada à coluna thumbnail, mas elas podem ser adicionadas aos metadados em meta_data["thumbnail_url"].
Recentemente, deparamos com situações em que nossas próprias tentativas de criar miniaturas a partir das URLs de imagens em tamanho completo causaram timeouts consistentes e impediram que os registros fossem exibidos nos resultados de pesquisa. O SMK é um exemplo recente disso: (1) (2). Pode ser vantajoso usar as miniaturas pré-calculadas pelo provedor nesses casos. É importante ressaltar que nem todos os provedores fornecem ou devem fornecer miniaturas. Assim, parece que talvez devêssemos reduzir a largura de nossas tabelas removendo essa coluna frequentemente vazia.
Proposta
Para image: primeiro percorremos todos os valores existentes de thumbnail no catálogo e os copiamos para meta_data["thumbnail_url"]. Em seguida, executamos uma troca de tabela por uma nova sem a coluna e removemos a coluna thumbnail da tabela. Isso ajudará a economizar espaço e reduzir a largura da tabela. Depois, atualizamos a visão materializada image_view para preencher uma coluna thumbnail para a APIAPI Uma API, ou Interface de Programação de Aplicações, é um intermediário de software que permite que programas interajam entre si e compartilhem dados de maneiras limitadas e claramente definidas. usando o dicionário meta_data. Um exemplo disso está na visão de Audioaudio_set_foreign_identifier. Isso nos permitirá manter a coluna thumbnail na API, mas reduzir o espaço no catálogo, já que uma migraçãoMigração Mover o código, o banco de dados e os arquivos de mídia de um site de um servidor para outro. Geralmente feito ao mudar de empresa de hospedagem. desse tamanho na API provavelmente seria inviável no momento. Em seguida, faremos duas alterações na lógica de ambos os lados:
- Adicionar a lógica de tratamento de
thumbnail_urlaoImageStore, que colocará esse valor automaticamente no dicionáriometa_data - Alterar a lógica do modelo Image na API para primeiro tentar usar
image.thumbnail(que foi copiado demeta_data["thumbnail_url"]durante a atualização dos dados) e, depois, tentar usarimage.urlao criar a imagem reduzida
Poderíamos fazer o mesmo para Audio; parece que cerca de metade dos registros não tem miniaturas:
deploy@localhost:openledger> select count(*) from audio where thumbnail is null;
+--------+
| count |
|--------|
| 427124 |
+--------+
SELECT 1
Time: 4.354s (4 seconds), executed in: 4.328s (4 seconds)
deploy@localhost:openledger> select count(*) from audio;
+--------+
| count |
|--------|
| 949384 |
+--------+
SELECT 1
Time: 3.899s (3 seconds), executed in: 3.887s (3 seconds)
O que vocês acham dessa abordagem? Acho que qualquer esforço para reduzir a largura de nossas tabelas do banco de dados é importante, pois isso facilitará as migrações e o gerenciamento de dados no futuro.