Estou acompanhando essa pergunta sobre valores estranhos em uma PERSISTED
coluna computada. A resposta lá faz algumas suposições sobre como esse comportamento surgiu.
Estou perguntando o seguinte: Isso não é um bug definitivo? É PERSISTED
permitido que as colunas se comportem dessa maneira?
DECLARE @test TABLE (
Col1 INT,
Contains2 AS CASE WHEN 2 IN (Col1) THEN 1 ELSE 0 END PERSISTED) --depends on Col1
INSERT INTO @test (Col1) VALUES
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5))
SELECT * FROM @test --shows impossible data
UPDATE @test SET Col1 = Col1*1 --"fix" the data by rewriting it
SELECT * FROM @test --observe fixed data
/*
Col1 Contains2
2 0
2 0
0 1
4 0
3 0
Col1 Contains2
2 1
2 1
0 0
4 0
3 0
*/
Observe que os dados parecem "impossíveis" porque os valores da coluna computada não correspondem à sua definição.
É sabido que funções não determinísticas em consultas podem se comportar de maneira estranha, mas aqui isso parece violar o contrato de colunas computadas persistentes e, portanto, deve ser ilegal.
Inserir números aleatórios pode ser um cenário artificial, mas e se estivéssemos inserindo NEWID()
valores ou SYSUTCDATETIME()
? Eu acho que essa é uma questão relevante que pode se manifestar praticamente.