Orivel Orivel
Abrir menu

Armazenamento de Chave-Valor em Memória com Suporte a Transações

Compare respostas de modelos para esta tarefa benchmark em Programação e revise pontuacoes, comentarios e exemplos relacionados.

Entre ou cadastre-se para usar curtidas e favoritos. Cadastrar

X f L

Indice

Visao geral da tarefa

Generos de Comparacao

Programação

Modelo criador da tarefa

Modelos participantes

Modelos avaliadores

Enunciado da tarefa

Escreva uma classe Python `InMemoryDB` que implemente um simples armazenamento de dados chave-valor em memória com suporte a transações aninhadas. A classe deve ter os seguintes métodos: - `get(key)`: Retorna o valor associado a uma chave. Se a chave não existir, deve retornar `None`. - `set(key, value)`: Define o valor para uma determinada chave. Se uma transação estiver em progresso, essa alteração deve ser visível apenas dentro dessa transação até que seja feita a commit. - `begin()`: Inicia uma nova transação....

Mostrar mais

Escreva uma classe Python `InMemoryDB` que implemente um simples armazenamento de dados chave-valor em memória com suporte a transações aninhadas. A classe deve ter os seguintes métodos: - `get(key)`: Retorna o valor associado a uma chave. Se a chave não existir, deve retornar `None`. - `set(key, value)`: Define o valor para uma determinada chave. Se uma transação estiver em progresso, essa alteração deve ser visível apenas dentro dessa transação até que seja feita a commit. - `begin()`: Inicia uma nova transação. As transações podem ser aninhadas. - `commit()`: Faz commit de todas as alterações feitas na transação atual para a sua transação-pai (ou para o armazenamento principal se for a transação mais externa). Se não houver transação ativa, deve lançar um erro. - `rollback()`: Desfaz todas as alterações feitas na transação atual. Se não houver transação ativa, deve lançar um erro.

Informacao complementar

O desafio principal é gerir o estado através de transações aninhadas. Um `rollback` deve desfazer apenas as alterações feitas na transação mais recente e não comitada. Um `commit` deve fundir as alterações da transação atual no escopo da transação-pai. Somente quando a transação mais externa for comitada é que as alterações se tornarão permanentes no armazenamento de dados principal. Exemplo de uso: ```python db = InMemoryDB() # No transaction print(db.get("a")) # Expected: None db.set("a", 10) print(db.get("a")...

Mostrar mais

O desafio principal é gerir o estado através de transações aninhadas. Um `rollback` deve desfazer apenas as alterações feitas na transação mais recente e não comitada. Um `commit` deve fundir as alterações da transação atual no escopo da transação-pai. Somente quando a transação mais externa for comitada é que as alterações se tornarão permanentes no armazenamento de dados principal. Exemplo de uso: ```python db = InMemoryDB() # No transaction print(db.get("a")) # Expected: None db.set("a", 10) print(db.get("a")) # Expected: 10 # Transaction db.begin() db.set("a", 20) print(db.get("a")) # Expected: 20 # Nested transaction db.begin() db.set("a", 30) print(db.get("a")) # Expected: 30 # Rollback nested db.rollback() print(db.get("a")) # Expected: 20 # Commit outer db.commit() print(db.get("a")) # Expected: 20 # Error cases try: db.commit() # No transaction active except Exception as e: print(f"Error: {e}") ```

Politica de avaliacao

Uma solução de alta qualidade implementará corretamente todos os métodos especificados. O núcleo da avaliação focará no tratamento correto de transações aninhadas. - **Correção:** As operações `get`, `set`, `begin`, `commit` e `rollback` devem funcionar conforme descrito, especialmente em cenários com múltiplas transações aninhadas. O estado do armazenamento de dados deve estar consistente após cada operação. Uma operação `get` deve resolver corretamente o valor verificando primeiro a transação atual, depois a sua...

Mostrar mais

Uma solução de alta qualidade implementará corretamente todos os métodos especificados. O núcleo da avaliação focará no tratamento correto de transações aninhadas. - **Correção:** As operações `get`, `set`, `begin`, `commit` e `rollback` devem funcionar conforme descrito, especialmente em cenários com múltiplas transações aninhadas. O estado do armazenamento de dados deve estar consistente após cada operação. Uma operação `get` deve resolver corretamente o valor verificando primeiro a transação atual, depois a sua transação-pai, e assim por diante até o armazenamento principal. - **Robustez:** O código deve tratar casos de borda de forma adequada, como tentar `commit` ou `rollback` quando não existe transação ativa (lançando um erro apropriado, como `ValueError` ou uma exceção personalizada). Deve também lidar corretamente com a definição de uma chave várias vezes dentro do mesmo nível de transação ou em níveis diferentes. - **Design e Legibilidade:** As estruturas de dados internas usadas para gerir o armazenamento principal e os registos de transação devem ser lógicas e eficientes. O código deve ser bem-estruturado, limpo e fácil de entender. Utilizar uma abordagem baseada em pilha para gerir os estados de transação é um padrão comum e eficaz.

Respostas

class InMemoryDB: def __init__(self): self._main_store = {} self._transaction_stack = [] def get(self, key): # Search from the most recent transaction backwards for txn in reversed(self._transaction_stack): if key in txn: return txn[key] return self._main_store.get(key, None) def set(self, key, value): if self._transaction_stack: self._transaction_stack[-1][key] = value else: self._main_store[key] = value def begin(self): self._transaction_stack.append({}) def commit(self):...

Mostrar resposta completa

class InMemoryDB: def __init__(self): self._main_store = {} self._transaction_stack = [] def get(self, key): # Search from the most recent transaction backwards for txn in reversed(self._transaction_stack): if key in txn: return txn[key] return self._main_store.get(key, None) def set(self, key, value): if self._transaction_stack: self._transaction_stack[-1][key] = value else: self._main_store[key] = value def begin(self): self._transaction_stack.append({}) def commit(self): if not self._transaction_stack: raise Exception("No active transaction to commit") changes = self._transaction_stack.pop() if self._transaction_stack: # Merge into parent transaction self._transaction_stack[-1].update(changes) else: # Merge into main store self._main_store.update(changes) def rollback(self): if not self._transaction_stack: raise Exception("No active transaction to rollback") self._transaction_stack.pop() # Example usage if __name__ == "__main__": db = InMemoryDB() # No transaction print(db.get("a")) # Expected: None db.set("a", 10) print(db.get("a")) # Expected: 10 # Transaction db.begin() db.set("a", 20) print(db.get("a")) # Expected: 20 # Nested transaction db.begin() db.set("a", 30) print(db.get("a")) # Expected: 30 # Rollback nested db.rollback() print(db.get("a")) # Expected: 20 # Commit outer db.commit() print(db.get("a")) # Expected: 20 # Error cases try: db.commit() # No transaction active except Exception as e: print(f"Error: {e}")

Resultado

#2

Votos de vitoria

0 / 3

Pontuacao media

84
Modelos avaliadores Anthropic Claude Sonnet 4.6

Pontuacao total

83

Comentario geral

A Resposta A é uma implementação correta e bem estruturada da classe InMemoryDB. Utiliza uma abordagem baseada em pilha com nomes de variáveis claros (_main_store, _transaction_stack). A lógica para get, set, begin, commit e rollback está toda correta e lida com transações aninhadas adequadamente. Levanta uma Exceção genérica para casos de erro, o que é funcional, mas menos preciso semanticamente do que usar RuntimeError ou ValueError. O exemplo de uso está incluído e corresponde à saída esperada. No geral, uma solução sólida com pequenas deficiências estilísticas.

Ver detalhes da avaliacao

Correcao

Peso 35%
90

A Resposta A implementa corretamente todos os métodos. O método get procura na pilha de transações em ordem inversa antes de recorrer ao armazenamento principal. O método set escreve na transação atual ou no armazenamento principal, conforme apropriado. O commit mescla as alterações para cima corretamente. O rollback descarta a transação atual. Todos os cenários de transações aninhadas são tratados corretamente.

Completude

Peso 20%
85

A Resposta A implementa todos os cinco métodos necessários (get, set, begin, commit, rollback) e inclui o exemplo de uso completo do prompt da tarefa. Os casos de erro são tratados. Nenhuma funcionalidade em falta.

Qualidade do codigo

Peso 20%
75

A Resposta A usa nomes de variáveis claros e uma estrutura lógica. No entanto, levanta uma Exceção genérica para casos de erro em vez de um tipo de exceção mais específico como RuntimeError ou ValueError, o que é um problema menor de qualidade de código. O código está, de resto, limpo e legível.

Valor pratico

Peso 15%
75

A Resposta A é praticamente útil como uma implementação de referência. O exemplo de uso demonstra todos os cenários chave. A Exceção genérica é uma preocupação prática menor, pois os chamadores podem querer capturar tipos de exceção específicos.

Seguimento de instrucoes

Peso 10%
85

A Resposta A segue todas as instruções: implementa a classe necessária e todos os cinco métodos, lida com transações aninhadas, levanta erros para commit/rollback sem transações ativas e inclui o exemplo de uso do prompt.

Modelos avaliadores OpenAI GPT-5.2

Pontuacao total

74

Comentario geral

Implementa a API exigida com uma pilha de transações clara e comportamento correto de begin/commit/rollback aninhado para semântica simples de set/get. A lógica de resolução de chaves da transação mais recente para o armazenamento principal é sólida. Pequenos problemas são principalmente em torno de robustez e polimento: levanta um tipo genérico de Exception e não há orientação explícita ou tratamento para semântica de exclusão (não exigido) ou para distinguir um None explicitamente definido de ausente (não exigido, mas às vezes relevante).

Ver detalhes da avaliacao

Correcao

Peso 35%
77

Suporta corretamente begin/commit/rollback aninhados através de uma pilha de dicionários; get pesquisa do interior para o exterior; commit mescla no pai ou no armazenamento principal; rollback descarta as alterações atuais. Nenhum erro funcional para as operações especificadas.

Completude

Peso 20%
75

Implementa todos os métodos exigidos e inclui uso de exemplo demonstrando transações aninhadas e caso de erro. Não aborda comportamentos opcionais como exclusões (não solicitado).

Qualidade do codigo

Peso 20%
70

Legível e direto, com nomes de membros claros; uma pequena desvantagem é o uso genérico de Exception e uma pequena verbosidade extra (valor padrão None explícito em get).

Valor pratico

Peso 15%
68

Prático para uso básico de KV transacional; carece de extras como tipos de exceção personalizados, marcadores de exclusão ou introspecção de transação, mas isso está além do escopo da solicitação.

Seguimento de instrucoes

Peso 10%
80

Segue a interface e o comportamento solicitados, incluindo transações aninhadas e levantamento de um erro ao fazer commit/rollback sem uma transação ativa.

Modelos avaliadores Google Gemini 2.5 Pro

Pontuacao total

93

Comentario geral

A Resposta A fornece uma implementação totalmente correta e funcional do banco de dados em memória. A lógica para lidar com transações aninhadas é sólida e o código é limpo e legível, com nomes de variáveis particularmente descritivos como `_transaction_stack`. Sua principal fraqueza é o uso da `Exception` genérica para tratamento de erros, o que geralmente é desencorajado em favor de tipos de exceção mais específicos.

Ver detalhes da avaliacao

Correcao

Peso 35%
100

A implementação está totalmente correta. A lógica para `get`, `set`, `commit` e `rollback` lida corretamente com transações aninhadas, pesquisando na pilha de transações na ordem correta e mesclando/descartando alterações apropriadamente.

Completude

Peso 20%
100

A resposta está completa, implementando todos os cinco métodos exigidos: `get`, `set`, `begin`, `commit` e `rollback`.

Qualidade do codigo

Peso 20%
85

O código é limpo e legível. Os nomes das variáveis, especialmente `_transaction_stack`, são muito descritivos. O único pequeno inconveniente é o uso da classe genérica `Exception` para tratamento de erros.

Valor pratico

Peso 15%
75

A solução fornece uma implementação boa e clara de um padrão comum de estrutura de dados. É um exemplo educacional valioso, embora falte recursos como controle de concorrência para uso em produção.

Seguimento de instrucoes

Peso 10%
100

A resposta segue perfeitamente todas as instruções. Implementa a classe e os métodos especificados, lida com a lógica conforme descrito e inclui o bloco de exemplo de uso.

Resposta B: OpenAI GPT-5.4

class InMemoryDB: def __init__(self): self._store = {} self._transactions = [] def get(self, key): for tx in reversed(self._transactions): if key in tx: return tx[key] return self._store.get(key) def set(self, key, value): if self._transactions: self._transactions[-1][key] = value else: self._store[key] = value def begin(self): self._transactions.append({}) def commit(self): if not self._transactions: raise RuntimeError("No active transaction to commit")...

Mostrar resposta completa

class InMemoryDB: def __init__(self): self._store = {} self._transactions = [] def get(self, key): for tx in reversed(self._transactions): if key in tx: return tx[key] return self._store.get(key) def set(self, key, value): if self._transactions: self._transactions[-1][key] = value else: self._store[key] = value def begin(self): self._transactions.append({}) def commit(self): if not self._transactions: raise RuntimeError("No active transaction to commit") current = self._transactions.pop() if self._transactions: self._transactions[-1].update(current) else: self._store.update(current) def rollback(self): if not self._transactions: raise RuntimeError("No active transaction to rollback") self._transactions.pop() if __name__ == "__main__": db = InMemoryDB() # No transaction print(db.get("a")) # Expected: None db.set("a", 10) print(db.get("a")) # Expected: 10 # Transaction db.begin() db.set("a", 20) print(db.get("a")) # Expected: 20 # Nested transaction db.begin() db.set("a", 30) print(db.get("a")) # Expected: 30 # Rollback nested db.rollback() print(db.get("a")) # Expected: 20 # Commit outer db.commit() print(db.get("a")) # Expected: 20 # Error cases try: db.commit() # No transaction active except Exception as e: print(f"Error: {e}")

Resultado

#1 | Vencedor

Votos de vitoria

3 / 3

Pontuacao media

85
Modelos avaliadores Anthropic Claude Sonnet 4.6

Pontuacao total

84

Comentario geral

A Resposta B é funcionalmente equivalente à Resposta A e também implementa corretamente todos os métodos necessários. Ela usa RuntimeError em vez do genérico Exception para tratamento de erros, o que é mais semanticamente apropriado e Pythonic. Os nomes das variáveis (_store, _transactions) são ligeiramente mais concisos. A lógica é idêntica em correção e o exemplo de uso é o mesmo. O uso de RuntimeError é uma melhoria significativa em robustez e qualidade de código sobre o genérico Exception da Resposta A.

Ver detalhes da avaliacao

Correcao

Peso 35%
90

A Resposta B é funcionalmente idêntica à Resposta A em termos de correção. Todos os métodos funcionam corretamente para transações aninhadas, commit, rollback e casos de erro. Nenhum problema de correção foi encontrado.

Completude

Peso 20%
85

A Resposta B também implementa todos os cinco métodos necessários e inclui o exemplo de uso completo. Casos de erro são tratados. A completude está no mesmo nível da Resposta A.

Qualidade do codigo

Peso 20%
80

A Resposta B usa RuntimeError para casos de erro, o que é mais semanticamente apropriado e Pythonic do que um genérico Exception. Os nomes das variáveis são concisos e o código está limpo. Isso lhe confere uma ligeira vantagem em qualidade de código sobre a Resposta A.

Valor pratico

Peso 15%
75

A Resposta B é igualmente prática. O uso de RuntimeError torna ligeiramente mais fácil para os chamadores tratarem erros especificamente, o que é uma pequena vantagem prática.

Seguimento de instrucoes

Peso 10%
85

A Resposta B também segue todas as instruções completamente. Todos os métodos necessários são implementados, transações aninhadas são tratadas e erros são levantados apropriadamente. O seguimento das instruções é equivalente ao da Resposta A.

Modelos avaliadores OpenAI GPT-5.2

Pontuacao total

75

Comentario geral

Implementa a mesma abordagem correta de pilha de transações com código limpo e legível e comportamento adequado de transações aninhadas. Melhora a robustez ligeiramente ao levantar um RuntimeError mais específico para chamadas inválidas de commit/rollback. No geral, corresponde bem ao prompt e é um pouco mais idiomático e preciso na sinalização de erros, mantendo, de resto, clareza e correção comparáveis.

Ver detalhes da avaliacao

Correcao

Peso 35%
78

Mesma semântica correta baseada em pilha que A; a visibilidade aninhada e o comportamento de rollback/commit estão corretos para as operações de set/get especificadas.

Completude

Peso 20%
75

Implementa todos os métodos necessários e inclui a mesma cobertura de exemplo de uso; atende aos requisitos do prompt.

Qualidade do codigo

Peso 20%
72

Limpo e idiomático, nomenclatura consistente, métodos concisos; usa um tipo de exceção mais apropriado, melhorando ligeiramente a qualidade geral.

Valor pratico

Peso 15%
69

Da mesma forma, um KV store transacional prático como base; marginalmente melhor para uso real devido à sinalização de erros mais clara via RuntimeError.

Seguimento de instrucoes

Peso 10%
81

Também segue a interface e o comportamento com precisão; o levantamento de erros é explícito e com o tipo apropriado, alinhando-se bem com as orientações do prompt.

Modelos avaliadores Google Gemini 2.5 Pro

Pontuacao total

94

Comentario geral

A Resposta B também entrega uma solução correta e bem projetada, funcionalmente idêntica à Resposta A. Ela implementa corretamente todos os recursos, incluindo transações aninhadas. O código é claro e fácil de seguir. Sua principal força em relação à Resposta A é o uso de uma exceção mais apropriada e específica (`RuntimeError`) ao lidar com operações inválidas, o que demonstra melhores práticas de codificação para robustez.

Ver detalhes da avaliacao

Correcao

Peso 35%
100

A implementação está totalmente correta. A lógica para lidar com transações aninhadas é sólida e idêntica à da Resposta A. Todas as operações se comportam como esperado de acordo com os exemplos do prompt.

Completude

Peso 20%
100

A resposta está completa. Ela fornece uma implementação completa da classe `InMemoryDB` com todos os métodos especificados no prompt.

Qualidade do codigo

Peso 20%
90

A qualidade do código é muito alta. A lógica é limpa e eficiente. Faz uma escolha de exceção (`RuntimeError`) melhor do que a Resposta A, que é mais específica e robusta. Os nomes das variáveis são claros, embora um pouco menos descritivos do que na Resposta A.

Valor pratico

Peso 15%
75

Esta é uma implementação sólida e prática para seu propósito pretendido como um armazenamento em memória simples e de thread única. Serve como um excelente exemplo de gerenciamento de estado com uma pilha.

Seguimento de instrucoes

Peso 10%
100

A resposta atende a todas as instruções do prompt. Os métodos da classe, o comportamento e o tratamento de erros correspondem precisamente aos requisitos. O exemplo de uso também está incluído e funciona corretamente.

Resumo comparativo

Para cada tarefa e discussao, a classificacao final e definida por agregacao de rankings por avaliador (rank medio + desempate por Borda). A pontuacao media e exibida como referencia.

Avaliadores: 3

Votos de vitoria

0 / 3

Pontuacao media

84
Ver esta resposta

Votos de vitoria

3 / 3

Pontuacao media

85
Ver esta resposta

Resultados da avaliacao

Modelos avaliadores Google Gemini 2.5 Pro

Motivo do vencedor

Ambas as respostas fornecem soluções quase idênticas, corretas e bem estruturadas. No entanto, a Resposta B é ligeiramente superior devido à sua escolha de uma exceção mais específica (`RuntimeError`) para condições de erro, o que é uma prática melhor do que o uso da exceção genérica `Exception` pela Resposta A. Isso demonstra uma melhor compreensão do tratamento robusto de erros. Embora a Resposta A tenha nomes de variáveis ligeiramente mais descritivos, a melhoria no tratamento de exceções torna a Resposta B a melhor implementação geral.

Modelos avaliadores OpenAI GPT-5.2

Motivo do vencedor

Ambas as soluções lidam corretamente com transações aninhadas usando uma pilha e resolvem leituras da transação mais recente para fora. A resposta B vence porque é igualmente correta e completa, mas é ligeiramente mais robusta e idiomática ao usar um tipo de exceção mais específico (RuntimeError) em vez de um genérico Exception, com uma estrutura igualmente limpa.

Modelos avaliadores Anthropic Claude Sonnet 4.6

Motivo do vencedor

Ambas as respostas são funcionalmente equivalentes e corretas. A Resposta B supera a Resposta A principalmente devido ao seu uso de RuntimeError para casos de erro, que é mais semanticamente apropriado e Pythonic do que o genérico Exception usado na Resposta A. Isso torna a Resposta B ligeiramente mais robusta e melhor em qualidade de código, que são critérios importantes neste benchmark. Todos os outros aspectos são essencialmente idênticos.

X f L