Diminui idas ao banco de dados na edição de usuários e na validação do token de confirmação do e-mail #1737
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mudanças realizadas
Fiz algumas melhorias para diminuir as idas ao banco de dados e isso também acabou simplificando algumas coisas. Similar ao processo que fizemos em #1729. Assim como no outro PR, fiz as alterações em commits pequenos para facilitar a identificação (e possível reversão) de cada etapa.
username
, e em alguns lugares ocorria umuser.findOneById
apenas para poder passar ousername
parauser.update
. Como em todos os lugares queuser.update
é chamado oid
é conhecido, agora ouser.update
utilizaid
ao invés deusername
.user.update
, recebeoptions.oldUser
para evitar uma nova busca pelo usuário sem necessidade. Interface similar aocontent.update
, que recebeoptions.oldContent
.user.update
, ao invés de chamarbalance.getTotal
duas vezes, faz como emfindOneById
e outras funções, buscando na mesma query que está sendo executada. Também criei um teste onde o usuário temtabcoins
etabcash
para garantir que o retorno estava correto.username
eemail
com uma única query.Também corrigi a função
validatePatchSchema
, que estava marcada como assíncrona desnecessariamente.Houve a mudança no valor de
error_location_code
de um erro lançado emmodels/email-confirmation.js
e outro emmodels/user.js
, não sei se isso é considerado breaking change. Se for, posso renomear o commit e marcar no PR que houve breaking change, ou então manter oerror_location_code
antigo (não sei se isso faz sentido).Tipo de mudança
Checklist: