PK에 대리 키를 사용하는 엔티티 클래스 A가 있고 다른 엔티티 클래스 B에 FK를 포함하는 고유성 제약 조건을 정의한다고 가정 해보십시오. 모두 훌륭하고 훌륭합니다. 그러나 어딘가에있을 때 엔, 엔티티 클래스 A가 B의 키 열 모두가 아니라 B의 키 열의 서브 세트에 의해 실제로 정의된다는 것을 발견했습니다.Entity Framework 5 마이그레이션에서 데이터베이스 리팩터링이 불가능합니까?
기본적으로 시나리오는 다음과 같습니다. 일부 열을 추가하고 이전 열을 제거하기 전에 기존 열 및 관계에있는 기존 데이터로 계산 된 값을 채우고 싶습니다.
표면 상으로는 쉽게 데이터 모델을 변경하고 새 마이그레이션을 추가 한 다음 Sql()에 대한 호출을 사용하여 T-Sql에서 데이터 모션을 수행하는 데 필요한 새 열을 삭제하고 이전 열을 삭제하기 전에
그러나 내 쿼리에서 새 열을 사용하면 문제가 발생할 수 있습니다. 이는 전체 마이그레이션이 배치 또는 다른 것으로 실행되는 것과 같습니다. 이 예에서
이 추가되는 새 열이 BNAME이며, 그 이전 마이그레이션의 실행에 B.에서 이름 열로 채우기에 단순한 운동이다, BNAME는 A에 존재UPDATE [dbo].[A] SET a.[BName] = b.[Name],
FROM [dbo].[A] a
FULL OUTER JOIN [dbo].[B] b ON a.[BId] = b.[Id]
이 수익률 :
System.Data.SqlClient.SqlException (0x80131904): The multi-part identifier "a.BName" could not be bound.
나는 GO 내가는 SQL()에 전달 쿼리 내에서 명령과 배치를 깨는 시도하지만,이 도구 세트에서 지원하지 않는했습니다.
System.Data.SqlClient.SqlException (0x80131904): Incorrect syntax near 'GO'.
EF의 현재 상태를 고려해 볼 때 가장 좋은 방법은 무엇입니까? 필자는 스키마 변경과 데이터 이동을 별도의 마이그레이션에서 수행 할 것을 제안했지만이 변경 사항의 논리적 원 자성으로 인해이 작업이 싫증이 나지 않는 것으로 나타났습니다. 어쩌면 나는 EF와 동시에 두 개의 개별 마이그레이션을 동시에 개발하여 소스 제어를 동시에 확인할 수 있지만 조직을 위해 단순히 완료되도록 불필요한 고통을 많이 겪고 있습니다.
편집 : 가치가있는 경우 the documentation on EFCF Migrations이 지원됨을 나타냅니다. 그러나 아직 내 것이 깨져있다. 그러나, 나는 이것이 프레임 워크의 단점이 아니라 내 부분에 어리석은 실수라는 희망으로 가득 차있다.