Termos mais procurados:
Entendo. Mas não faria sentido eles "traduzirem" isso pra outro formato internamente. O formato de configuração normalmente representa o mesmo formato que está sendo "guardado" (e processado) internamente. Por isso, fiz questão de sugerir que mudem enquanto não foi feito deploy. É aquele tipo de coisa que se deixar pra arrumar depois que "o barco já partiu", ficam presos no problema.
Sim, mas eles podem implementar isso no recebimento mesmo que a configuração seja de uma forma menos otimizada.
A minha preocupação foi 0% em relação ao EC. Foi 100% do lado da GN em relação ao desempenho que ela vai ganhar não precisando iterar esse array em todo recebimento. Todo array que depende de um loop que o percorra para que seus elementos internos sejam identificados (e condicionantes sejam aplicadas) é um array "burro". O identificador deve ser a chave do elemento, sempre que possível. Verificar se pix[chaves][123] existe não exige que eu leia todos os elementos em chaves (e muito menos todos os seus valores internos). Ganha-se absurdamente em velocidade e em consumo de memória - e isso mesmo quando só houver 1 elemento no array. Um teste array_key_exists() tem um processamento ínfimo perto de qualquer tipo de loop. Isso pode ser comparado à uma busca em banco de dados em diferentes colunas, uma com índice e a outra sem.
Faz sentido, a questão que já está em desenvolvimento, com entrega prevista para essa semana que inicia, e como é importante fazermos logo, não sei se conseguiríamos fazer algo por agora, o que acha <@!816632817441177600> ?
A estrutura de dados do config e a estrutura de dados do atendedor de recebimentos não precisam ser a mesma. Eles podem fazer essa otimização em uma e não na outra... ou podem fazer nas duas. Mas a transação de config ocorre bem raramente, então dá bem na mesma...
.... porém, sua sugestão me parece mais alinhada com a estrutura da API do BACEN. Então por motivos diferentes, eu também apoio.
isso no endpoint /gn/config, certo? esse endpoint já está em uso? vi ele ser comentado aqui no <#💭sugestões> mas não me recordo de alguma config que já tenha sido implantada.
se não foi (ou se foi mas ainda não existe esse índice chaves) eu iria sugerir modificar a estrutura interna dele, passando a usar as chaves como índice das configurações que são definidas por chave.
assim vocês ganhariam em desempenho: não iriam precisar iterar o array chaves e ler o valor de chave em cada um deles para encontrar qual se refere à chave 123 onde um pix tenha entrado. bastaria procurar pela existência do elemento pelo seu índice, pix[chaves][123] (assim como __eu acho__ que já é feito para o cadastramento dos webhooks, por exemplo). o ganho é marginal em 1 recebimento mas pode ser significativo em volume.
Ele quis dizer que 0, 1 ou “0” são representados da mesma forma neste contexto, pois não tem definição de se é string, inteiro e etc
Bom dia, são só casos de testes, não entendi o que você quis dizer com estáticos nem tratamento especial...
No fundo tudo isso pq o BACEN não pensou no caso de uso de carregamento de contas. Talvez sugerir algo, como as elétricas fizeram no reuso de location ?
Sugestões que me lembre até agora:
- Utilizar % bem parecido com o LIKE do MySQL;
- Utilizar iniciaCom e terminaCom;
- Utilizar o regex bloqueando o uso de "()" (faria com que não demorasse tanto);
- Enviar uma requisição para uma URL para homologar um txid, ex: {webhookUrl}/txidmatch (Essa necessitaria de uma homologação parecida com BACEN x PSP);
Pessoal, boa tarde.
Segue a nossa proposta (inclusive já em andamento) que contempla somente, e apenas inicialmente, as travas de recebimentos de Pix sem txid's, bem como eventual bloqueio geral de recebimento a partir de QR Codes Estáticos (esse segundo ponto veio porque vimos ser uma mudança simples e de ampla aplicabilidade).
e o BACEN tá avaliando, inclusive, mudar a especificação BRCode, passando a aceitar a omissão do campo 62, e aí não teria mais o nem nos qr codes. https://github.com/bacen/pix-api/issues/245
Estamos considerando aqui o que informaram <@!440035527127990273> e demais, vamos fechar uma abordagem inicial aqui e em breve trazemos para a apreciação de vocês.
o único caso especial possível que não seria coberto apenas com os 2 validadores txidNulo e txidEstatico seria um PSP pagador tratar erradamente o txid como int em algum ponto do seu sistema e acabar enviando "0" na PACS em vez de uma string vazia, ou omitir o campo txid, fazendo a validação da GN testar contra a opção de aceite de Pix via qr estático em vez de testar contra o Pix de txid nulo, o que eu não vi ninguém reportar e acho difícil que aconteça (por ser o txid um campo que acata caracteres a-z também). por isso que acho suficientes essas 2 opções. simples e funcionais. e em último caso, a GN poderia tratar a string "0" como txidNulo em caráter de exceção.
