Listar conteúdos por quantidade de TabCoins, comentários, data de atualização etc.

[iget-master]

Caso de uso: quero ver meus melhores e piores conteúdos, então posso ordenar eles por tabcoins (crescente ou decrescentemente)

Acredito que seja simples de implementar.

O que acham?

[kenionatan]

Hey @iget-master, sou novo aqui, não sei se isso é algo que já foi comentado aqui, dei uma pesquisada e não achei nada, caso não exista nada em andamento neste sentido posso ajudar na implementação.

[hkotsubo]

Eu iria além e incluiria logo vários critérios: data da última atualização (seja comentário ou edição), votos, quantidade de comentários, etc (todos com opção de ordem crescente e decrescente).

[aprendendofelipe]

@iget-master, obrigado pela sugestão! 💪

Por enquanto não existe cache dos saldos de TabCoins dos conteúdos. Então eles são computados dentro de cada consulta em que são necessários. Por exemplo, para criar a lista de relevantes, buscamos todos os conteúdos root da última semana e computamos o saldo de cada um deles antes de fazer as próximas etapas de classificação.

Note que, enquanto não houver cache do saldo, fica inviável computar o saldo de todos os conteúdos existentes para poder classificá-los pelo saldo.

Mesmo que filtrando por usuário, teria que limitar também por uma certa quantidade de conteúdos, então não seria um resultado real de todos os conteúdos do usuário, mas apenas dos mais recentes.

Já as demais possibilidades sugeridas pelo @hkotsubo, acho que agora são viáveis, e é só questão de alguém contribuir com a implementação. 🤝

[Rafatcb]

@aprendendofelipe O cache que você menciona seria o que exatamente? Vi que foi considerado adicionar um tabcoins_accumulated no users, acredito que o mesmo raciocínio serviria para contents:

As propriedades tabcoins_accumulated e tabcash_accumulated serão removidas e vamos implementar isso em outro momento.

Pelo comentário que vi no TabNews, parece que o Pagar.me criou uma outra tabela para o saldo, então não entendi se poderíamos ou não criar a coluna tabcoins_accumulated na tabela contents mesmo. Nessa publicação do TabNews tiveram outros comentários sugerindo adicionar uma ou duas colunas à tabela balance_operations.

De toda forma, me parece que seria melhor salvar tabcoins_credit e tabcoins_debit ao invés de tabcoins_accumulated, porque eu cheguei nesse assunto devido ao issue https://github.com/filipedeschamps/tabnews.com.br/issues/1370, que hoje é bem simples de resolver (seguiria a mesma lógica de cálculo do total), mas com esse "cache" deveria continuar possível obter os "créditos" e "débitos" com o mesmo custo de desempenho do "total", para não precisar fazer um cálculo caro e um barato na query, por exemplo.

Nesse vídeo o Filipe comenta sobre a coluna sequence em balance_operations que foi criada para preparar para o estágio do cache, mas não entendi bem o motivo. Minha suspeita é que seria usado para verificar até qual evento foi considerado no cache.

[filipedeschamps]

@Rafatcb a mecânica de cache é mais ou menos a seguinte:

Duas tabelas são envolvidas, uma que anota de forma livre todas as operações (a que já temos hoje balance_operations) e uma outra que anota a soma do saldo (por exemplo balance_sum). Lá tem o valor calculado do saldo do usuário, mas a questão que fica é: como fazer para atualizar esse valor somado? É aí que entra a função do sequence. Essa segunda tabela possui uma coluna que registra qual foi o último sequence que foi usado no cálculo e isso significa que o saldo somado foi de suposto sequence 0 até sequence x. Então quando a função que pede pelo saldo é chamada, ela faz mais coisas:

1. Da balance_sum, pega o valor atual de saldo já somado e o sequence.
2. Verifica se existem mais lançamentos em balance_operations acima do sequence anotado no balance_sum.
3. Se tiver, levanta o saldo somente do sequence para frente e soma isso com o saldo que já estava somado no balance_sum.
4. Feito isso, atualiza o sequence no balance_sum com o último utilizado do balance_operations para aquele usuário.

Então você tem uma tabela com o saldo fragmentado e na outra tabela o saldo consolidado, sendo que para consolidar o saldo, você não precisa mais passar por todos saldos fragmentados, basta somar o diff dos novos registros fragmentados. Isso faz muita diferença quando um certo usuário (ou empresa no caso do Pagar.me) possui milhões de balance_operations. A diferença de performance era absurda, porque as vezes por erro nosso a gente precisava recalcular o saldo e demorava muito.

Não lembro se era exatamente assim a implementação, mas em princípio era isso. Posso marcar um call com a turma de lá para revisar a mecânica.

E no nosso caso, dá para criar mais tipos de cache (cache de positivos ou negativos). De qualquer forma, eu só faria essa implementação quando a performance da soma crua for um problema real.