단일 데이터베이스 멀티 테넌시는 데이터 격리를 강제하기 위해 organization_id 컬럼에 의존하지만, 개발자는 쿼리에 이를 포함하는 것을 잊지 않아야 합니다. Doctrine의 SQLFilter는 이를 자동화할 수 있지만, 그 효과는 구현 위치와 생략 위치에 따라 달라집니다. 조직 필터는 fixtures, migrations, 복구 스크립트와의 문제를 방지하기 위해 기본적으로 Doctrine 설정에서 의도적으로 비활성화되어 있습니다. 인증된 사용자와 그들의 조직에 접근하기 위해 요청 라이프사이클 후반부, 특히 방화벽 이후에 리스너에 의해 활성화됩니다.그러나 이 필터에는 적용되지 않거나 우회되는 몇 가지 사각지대가 있습니다. 콘솔 명령과 메시지 큐 워커는 요청 리스너의 이점을 누리지 못하므로 필터가 활성화되지 않은 상태로 실행됩니다. 이는 모든 테넌트에 걸친 배치 처리와 같은 작업에는 의도된 것이지만, 테넌트 데이터에 영향을 미치는 명령에는 명시적인 범위 지정이 필요합니다. 관리자 패널도 경로 접두사를 통해 의도적으로 면제되어 테넌트 간 데이터를 볼 수 있도록 하므로 이러한 면제는 보안에 매우 중요합니다.쿼리가 실행되기 전에 Doctrine의 identity map에 있는 엔티티는 SQL이 생성되지 않으므로 필터를 완전히 우회합니다. 마찬가지로, getReference()는 데이터베이스 상호 작용 없이 프록시를 생성하므로 필터는 프록시가 초기화될 때까지 고려되지 않습니다. DBAL을 통해 실행되는 네이티브 SQL 쿼리는 Doctrine 필터를 완전히 무시하므로 보고 및 내보내기 기능에 위험을 초래합니다. 루트 엔티티에 organization_id와 마커 인터페이스가 없는 경우 조인 상속도 필터링 누락으로 이어질 수 있습니다. 통념과는 달리, 필터는 대량 UPDATE 및 DELETE DQL 문에 적용되지만, 이는 DQL 경로만 해당됩니다. 필터의 신뢰성을 보장하고 회귀를 포착하기 위해서는 철저한 자동화 테스트가 중요합니다.