왜 flag_shih_tzu가 bit flags에 대한 기본 SQL을 변경하고 있나요?

Source: Dev.to

배경

flag_shih_tzu는 여러 개의 불리언 속성을 하나의 정수 컬럼에 저장하며, 플래그당 하나의 비트를 할당합니다.
버전 1.0.0에서는 다비트 플래그, 삼진 플래그, 열거형 플래그에 대한 지원이 추가되었습니다.

class User  :warpdrive,
            2 => :shields
end

IN‑list 쿼리 문제

과거에는 gem이 단일 플래그를 조회하기 위해 IN() 리스트를 생성했습니다:

SELECT * FROM users WHERE flags IN (1, 3);

애플리케이션이 정확히 두 개의 플래그(값 1과 3)를 알고 있을 때는 정상적으로 동작합니다.
하지만 롤링 배포 중에 새로운 플래그가 추가될 수 있습니다:

class User  :warpdrive,
            2 => :shields,
            3 => :premium
end

마이그레이션(또는 백그라운드 작업)이 기존 행에 새로운 비트를 설정합니다:

UPDATE users
SET flags = flags | 4
WHERE created_at  :warpdrive,
          2 => :shields,
          flag_query_mode: :in_list

:in_list 모드는 여전히 지원되지만 더 이상 가장 안전한 기본값은 아닙니다.

성능 고려 사항

• IN‑list 쿼리는 가능한 플래그 조합 집합이 고정되고 잘 알려진 경우, 일부 데이터베이스와 특정 인덱스에서 더 빠를 수 있습니다.
• Bit‑operator 쿼리는 플래그가 시간이 지나면서 추가될 때(특히 롤링 배포 중) 정확성을 보장합니다. 또한 일반적인 정수 인덱스와도 잘 작동합니다.

워크로드에 가장 적합한 모드를 선택하되, 기본값은 정확성을 우선시해야 합니다.

결론

flag_shih_tzu는 이제 :bit_operator를 기본값으로 사용합니다. 이는 플래그 집합이 진화할 때도 안정적으로 처리하여 배포 중 정적 IN‑list 쿼리의 함정을 피합니다. 플래그 집합이 안정적이고 성능 이점을 측정한 경우에만 :in_list를 사용하십시오.