No PostgreSQL, é necessário otimizar o desempenho das transações através de um nível de isolamento mínimo, no qual: • transações paralelas podem ver alterações não finalizadas umas às outras; • são possíveis "leituras sujas" (dirty read). Qual nível de isolamento deve ser especificado para a transação para atingir esse objetivo? dirty read não é possível no PostgreSQL leitura repetível leitura não confirmada leitura confirmada serializável
Qual estratégia seria eficaz para eliminar a vulnerabilidade em todos os ramos com o mínimo risco de perturbar o funcionamento do projeto? - Criar uma série de commits de revert para o commit problemático e todos os commits que o corrigiram parcialmente, depois criar um novo commit com a correção completa - Criar um ramo hotfix a partir de um ponto anterior ao commit problemático, fazer as correções e mesclar esse ramo com todos os ramos afetados - Criar um commit de correção único usando git revert abc123 na branch principal e depois fazer cherry-pick desse commit em todas as branches de lançamento - Usar git bisect para determinar exatamente o código problemático, criar um patch e aplicá-lo a todas as branches usando git am - Usar git rebase -i para editar o commit problemático em cada branch, seguido de um push forçado (force-push)
Existem duas transações. Primeiro, a primeira transação executa um comando. Depois, a segunda transação executa um comando. Em seguida, a primeira transação continua a ser executada. Qual sequência levará a um bloqueio mútuo? ```sql -- primeira transação update accounts set balance = balance + 100 where id = ?; -- segunda transação update accounts set balance = balance - 50 where id = ?; update accounts set balance = balance + 200 where id = ?; ```
Como recuperar o trabalho de uma branch remota se ao tentar fazer `git checkout hotfix/missing-footer` receber uma mensagem de erro dizendo que a branch não foi encontrada?
Análise da atividade dos utilizadores em campanhas publicitárias A empresa mantém um registo de eventos relacionados com campanhas publicitárias. São fornecidas duas tabelas: • campaigns — lista de campanhas publicitárias com os seus identificadores e nomes; • events — eventos de utilizadores por campanha com informações sobre o tipo de evento (por exemplo, 'click' (clique na publicidade)) e o tempo. É necessário criar um relatório para cada campanha com os seguintes indicadores: • Número total de eventos. • Número de utilizadores únicos que realizaram eventos. • Hora do primeiro e do último evento por campanha. • Classificação da campanha por ordem decrescente do número total de eventos. A classificação é um número atribuído a cada linha no conjunto de resultados com base na ordem dos dados. Se duas ou mais linhas tiverem o mesmo valor, recebem a mesma classificação, mas a classificação seguinte é pulada. O relatório deve incluir apenas campanhas que tiveram eventos: campanhas sem eventos não são consideradas. O relatório final deve ser ordenado primeiro pela classificação da campanha em ordem crescente, e depois por campaign_name em ordem alfabética. Formato de entrada • campaign_name (string) — nome da campanha publicitária • start_date (timestamp) — data e hora de início da campanha • end_date (timestamp) — data de fim da campanha Tabela events: • event_id (int) — identificador único do evento • user_id (int) — identificador único do utilizador que realizou o evento • campaign_id (int) — identificador único da campanha • event_type (string) — tipo de evento, por exemplo 'click' ou 'conversion' • event_time (timestamp) — data e hora do evento Os dados não contêm valores em falta ou incorretos. Formato de saída A consulta deve retornar uma tabela com os campos nesta ordem: • campaign_name (string) — nome da campanha publicitária • total_events (int) — número total de eventos relacionados com a campanha • unique_users (int) — número de utilizadores únicos que realizaram eventos • first_event_time (timestamp) — data e hora do primeiro evento da campanha • last_event_time (timestamp) — data e hora do último evento da campanha • campaign_rank (int) — classificação da campanha por ordem decrescente do número total de eventos Ordene os dados por classificação da campanha em ordem crescente, e depois por campaign_name em ordem alfabética.
O que deve fazer se quiser alterar o ramo para o qual o submódulo aponta? - Submódulos não suportam mudança de ramos - Eliminar o submódulo e adicioná-lo novamente com o ramo desejado - Alterar o ramo no submódulo e fazer um commit no repositório principal - Executar git checkout no ramo desejado no submódulo e registar as alterações no repositório principal - Executar git submodule update --branch especificando o novo ramo
Por que está a considerar ofertas de emprego neste momento?
O que aconteceu e como recuperar o trabalho?
No PostgreSQL, o cabeçalho de versão da linha inclui o parâmetro xmax. Qual é o seu papel na gestão de transações? - Para criar um identificador único de linha na tabela - Para verificar a visibilidade da linha por outras transações - Para indicar o número de transação que excluiu ou atualizou a linha - Para bloquear a linha contra alterações simultâneas por várias transações - Para indicar o valor máximo que pode ser registrado numa coluna numérica
A ramificação feature contém vários commits com um arquivo config.yaml mal commitado, que foi corrigido posteriormente. Como resultado, a equipe decidiu remover completamente todas as alterações no arquivo da história para evitar a divulgação de configurações confidenciais. Estado original da ramificação (saída do git log --oneline): 1 a4b5c67 (HEAD -> feature) Refatorou a lógica do serviço 2 d9f0a11 Corrigiu erro de digitação no config.yaml 3 7c1d3f2 Adicionou um config.yaml temporário 4 e3a98cd Commit inicial 5 Após reescrever a história para remover o arquivo config.yaml, a saída do git log --oneline ficou assim: 6 b9e7d42 (HEAD -> feature) Refatorou a lógica do serviço 7 41f3b60 Commit inicial Que operação a equipe realizou? - Executou git revert no commit com o config.yaml - Executou git filter-branch --index-filter "git rm --cached config.yaml" -- --all - Executou git rebase -i removendo commits que continham alterações no arquivo - Executou git commit --amend e git push --force - Executou git cherry-pick para criar uma nova ramificação sem o config.yaml
A tabela notifications contém um campo status, no qual os valores são: 'sent', 'delivered', 'read'. Qual das consultas está correta? select * from notifications where status like '%sent%' order by created_at desc limit 5 select * from notifications where status = 'read' order by created_at desc limit 5 select * from notifications order by status desc limit 5 select * from notifications where status not in ('sent', 'delivered') order by created_at asc limit 5 select * from notifications where status in ('sent', 'delivered') order by created_at desc limit 5
Por favor, conte-nos por que está interessado nesta vaga.
Foi criada a estrutura de tabelas indicada na imagem. É necessário executar a consulta indicada na imagem. Que tipo de join deve ser usado no lugar de [...], para que no resultado, os registos com type = 'table_aw' tenham a coluna 'naming' preenchida, e para os registos com type = 'table2' tenham a coluna 'serial_number'? create table multirelation( type varchar not null, entity_id integer not null ); create table table_aw( id integer primary key, naming varchar not null ); create table table2( id integer primary key, serial_number varchar not null ); -- estrutura das tabelas select m.type,m.entity_id, ta.naming, t2.serial_number from multirelation m [...] join table_aw ta on m.entity_id = ta.id and m.type='table_aw' [...] join table2 t2 on m.entity_id = t2.id and m.type='table2'; -- consulta Deixar em branco inner cross right left
Qual comando, a partir da pasta raiz do projeto, deve ser usado para atualizar o submódulo docs/ para a última versão do repositório remoto e preparar essa alteração para o commit? git fetch docs/ && git merge docs/FETCH_HEAD git pull --recurse-submodules git submodule update --remote docs/ cd docs/ && git pull && cd .. && git commit -am "Atualização" git submodule update --init docs/
Análise da frequência em clubes de fitness Você trabalha como analista numa cadeia de clubes de fitness. Tem informações sobre as visitas dos utilizadores e as assinaturas que eles compram. É necessário analisar a eficácia do uso das assinaturas. Calcule para cada tipo de assinatura: • o número total de utilizadores que usaram esse tipo de assinatura. Considere apenas user_id únicos; • o número total de visitas com essa assinatura. Considere todas as visitas de utilizadores com essa assinatura; • a proporção de utilizadores dessa assinatura em percentagem do total de todos os utilizadores (arredondado a uma casa decimal). Para calcular a proporção de utilizadores, use a relação entre o número de utilizadores com essa assinatura e o número total de utilizadores únicos. Cada utilizador pode ter apenas uma assinatura. Ordene o resultado por tipo de assinatura em ordem alfabética. Formato de entrada Tabela memberships: • membership_id (int) — identificador único da assinatura • user_id (int) — identificador único do utilizador • membership_type (text) — tipo de assinatura Tabela visits:
Precisa reverter rapidamente vários ficheiros para a versão do último commit, sem afetar as outras alterações. Como proceder? git reset --hard HEAD Eliminar e recriar os ficheiros manualmente git fetch e git merge git revert HEAD git checkout HEAD^ <ficheiro1> <ficheiro2>
O que aconteceu e como recuperar o trabalho?
Com que projetos em Scala trabalhou anteriormente? Compartilhe tarefas específicas e conquistas nesta tecnologia.
O que se pode dizer sobre a correção da seguinte consulta? select * from sessions where ended_at is null and status != 'pending';
Tem duas tabelas relacionadas: first_table e second_table. Deseja executar o comando TRUNCATE TABLE second_table CASCADE;, para remover todas as linhas da tabela second_table e todos os dados dependentes dela. Quais podem ser as consequências de executar este comando? create table first_table ( id integer primary key ); create table second_table ( id serial primary key, first_table_fk integer references first_table(id) ); - A sequência second_table_id_seq será redefinida para o valor inicial. - Todas as entradas de first_table relacionadas por chave estrangeira a second_table serão removidas. - Os índices existentes para second_table serão removidos e recriados automaticamente. - Em inserções subsequentes em second_table, o valor padrão para id pode começar de um valor incorreto. - Um erro ocorrerá, pois o comando CASCADE é proibido para tabelas com chaves estrangeiras.
