2010-12-03 3 views
4

여러 개발자 간의 데이터베이스 변경을 처리하기 위해 Doctrine 마이그레이션을 내 환경에 배치하려고합니다. 나는 전에 그들을 사용하지 않았지만 나는 그 문제에 대한 나의 연구를했다.Doctrine Migrations Re. Fixtures

이 시점에서 나의 유일한 관심사는 [내가 말할 수있는 한] Doctrine 마이그레이션은 조명기 수정을 허용하지 않는다는 것입니다. 마이 그 레이션은 설계도 변경을위한 것이라는 것을 알고 있지만, 픽스쳐 변경이 중요하다고 생각합니다.

참조 테이블에 대한 비품을 내 데이터베이스 (예 : * _type, * _source 등)로 만들고 싶습니다. 그리고이 마이그레이션에서도 추가/삭제/업데이트 행을 처리해야합니다. 구조적 변화만큼이나 중요합니다.

누구나 올바른 방향으로 나를 가리킬 수 있다면, 대단히 감사하겠습니다.

업데이트

는 단순히 SVN 내 참조 테이블기구를 추적시키기의 아이디어를 탐구하지만, 이것은 배포를 취소 할 해결책이 될 것입니다. 테이블은 외래 키 제약으로 인해 잘 리거나 다시 채워질 수 없습니다.

답변

2

당신이 지적했듯이 마이그레이션은 데이터베이스의 구조적 변경을 용이하게하기위한 것이지, 조명기 데이터를 따라 조작하는 것이 아닙니다.

제 경험상, 응용 프로그램이 개발 중일 때 마이그레이션을 사용하는 것이 가장 도움이되는 방법은 아니며, 특히 개발자 A가 새 마이그레이션을 생성하고 즉시 커밋하지 않을 경우 개발자 B는 새로운 마이그레이션을 만듭니다 개발자 A의 마이그레이션과 무의식적으로 충돌 한 다음 즉시 체크인합니다. 개발자 A는 곧 자신의 마이그레이션을 확인하고 충돌하는 두 가지 마이그레이션이 있으며 세계가 폭발합니다.

schema.yml에서 스키마 변경을 수행하고 (개인 마이그레이션 또는 수동으로) 스키마 변경 사항을 적용한 다음 doctrine:data-dump을 커밋하는 것이 더 낫겠지 만 (길기는하지만) 조명기 데이터.

개발 중에 마이그레이션을 선택하는 경우 Doctrine Migration 클래스의 ->postUp()->preUp() 메서드를 사용하여 데이터를 원래대로 변환하는 것이 좋습니다.

+0

이것은 정확하게 내가 원하는 것 같습니다 (ref http://www.doctrine-project.org/projects/orm/1.2/docs/manual/migrations/en#writing-migration-classes:pre-and). -post-hooks). 고마워, 잔민. 또한 접근 방식이 더 나은 접근 방법 인 것처럼 보이지만 정기적 인 구조 변경을 생산으로 옮기는 것이 얼마나 쉬운 지 확신 할 수 없습니다. – Craige

+0

Doctrine Migrations은 꽤 멋지다. 재미있게 – BenLanc

+0

@MrJasmin, sqlite를 사용하지 않는 한 .. Doctrine : data-dump는 sqlite에서 마이그레이션을 수행하는 유일한 방법이다. – Dziamid