2011-02-16 4 views
17

프로젝트의 무거운 초기 개발 중에 (django) South을 사용하는 이점에 대해 궁금합니다.초기 개발 과정에서 South를 사용하는 이유는 무엇입니까?

개발 초기에는 일반적으로 빠른 모델 변경, 자주 분기 및 병합 (특히 git-flow와 같은 개발 전략을 사용하는 경우) 및 저장된 데이터가 거의 존재하지 않습니다. 왜 초기 모델 변경을 계속하고 싶습니까? 장점/단점은 무엇입니까?

South를 활성화하고 초기 마이그레이션을 수행하기 전에 개발이 완료 될 때까지 (그리고 실제로 보관하려는 데이터가있을 때까지) 기다리는 것이 더 쉽다는 인상을 받고 있습니다. 그렇게 할 수 있습니까? 그렇게하고 싶습니까?

+0

동의합니다. 이것은 장고가 현재와 같이 매우 초조하기 때문에 코어에서 일부 통합 스키마 변경 기능이 필요하다고 생각하는 이유입니다. –

+0

@meder 마이 그 레이션 시스템없이 어떻게 그렇게 제안합니까? 내 마음 속에, 남쪽은 그 차이를 잘 채 웁니다. – Kekoa

+0

데이터베이스에 영향을주는 모든 모델을 변경 한 후에 버전 제어 파일 evolve.sql을 SQL 명령에 붙여두면됩니다. 또한 데이터 집중적 인 마이그레이션 변경 사항을 위해 저수준 DB 래퍼 (필자의 경우 MySQLdb)를 사용하는 evolve.py가 있습니다. 코드가 적고 잘못 될 일이 적습니다. 데이터에 관해서는 일이 잘못되기를 바라지 않을 것입니다. –

답변

16

다른 사람이 사용해야하는 커밋을 실행하는 즉시 작업 복사본을 만들 수 있도록 마이그레이션을 만듭니다.

혼자 일하는 경우 (배포 걱정할 필요가 없음) 이는 문제가되지 않으며 마이그레이션을 만들 수있는 마지막 순간까지 기다릴 수 있습니다.

일단 다른 사용자와 작업을 시작하면 마이그레이션을 신속하게 수행하여 작업 흐름을 습득하고 모든 사람이 동일한 데이터베이스 페이지에 있도록하기 쉽습니다.

또한 단순히 필드를 수정하는 경우 syncdb를 사용할 수 없습니다. 필드를 추가, 삭제 또는 수정하기 위해 테이블을 날려 버리는 것은 엄청나게 짜증납니다.

내가 추가 한 스키마 마이그레이션은 여러 번 결합하여 (롤백하고 삭제하고 새로운 점보 마이그레이션을 생성하는 경우) 단일 마이그레이션으로 통합합니다. 하지만 일반적으로 마이 그 레이션 횟수는 실제로 비용이 들지 않기 때문에 저를 괴롭히지 않습니다.

2

초기 개발 중에는 South를 사용하지 않습니다. 난 단지 a script 각 애플 리케이션에 대한 비품을 생성하므로 스키마가 변경되면 이전 테스트 데이터를 덤프하고 스키마를 편집하고 테스트 데이터를 업데이트하여 새 스키마에서 작동하도록 만든 다음 데이터를 복원하십시오.

0

특정 단계의 남쪽을 사용하고 초기 마이그레이션을 수행 할 수 있습니다. 여기에 진실 문서 : http://south.aeracode.org/docs/tutorial/part1.html#converting-existing-apps

나는 UI 나 그런 것들을 테스트하기 위해 자주 사용하는 데이터를 가지고 있으므로 개발 중에는 남쪽을 사용합니다. South은 또한 모든 모델 변경 후에 완전히 새로운 데이터베이스로 시작하지 않으면 데이터베이스 일관성을 유지하는 데 매우 유용합니다. 그래서 나는 장고에 동의한다. 장고가 스키마 이주를한다면 좋을 것이고, 다른 한편으로는 남쪽을 구현하는 것이 쉽지는 않다.

4

나는 개발 도중 테이블 필드가 자주 변경되기 때문에 South가 개발과 마찬가지로 유용하다는 것을 알았습니다. 테이블을 삭제하고 하나의 필드를 추가하기 위해 syncdb를 사용하여 테이블을 다시 만들어야하는 것은 매우 귀찮습니다. 특히 테스트 데이터가있는 경우 특히 그렇습니다. (DBMS에서 직접 테이블을 수정할 수도 있지만, Django가 기대하는 것과 동일한 필드 유형을 사용하고 ON DELETE와 같은 속성을 적절하게 설정하는 등주의해야합니다. 또한 다른 사람이 프로젝트에서 작업하는 경우 데이터베이스 사본과 동일한 변경 사항을 적용하도록 프로젝트 담당자에게 알려야합니다. 남쪽은 훨씬 더 단순 해집니다.

South에서 이전 마이그레이션을 모두 삭제할 수 있다면 멋지 겠지만 초기 개발자를 마무리하고 실제 데이터를 추가 할 때 깨끗한 슬레이트로 시작할 수 있습니다. 하지만 궁극적으로 여섯 개 정도의 추가 마이그레이션 파일로 인해 비용이 들지 않습니다.

+0

이전의 모든 마이그레이션을 삭제하는 것과 관련하여 현재 스키마 (syncdb를 모방 한 것)에서 시작하려면 데이터베이스의 모든 테이블을 삭제하고 모든 마이그레이션을 제거한 다음 각 응용 프로그램에 대한 스키마 마이그레이션을 수행하면됩니다. – Kekoa

0

좋은 소식 - 2014 년 9 월 2 일 현재 마이그레이션은 코어 장고 1.7 버전의 일부입니다.

https://docs.djangoproject.com/en/dev/releases/1.7/

난 그냥 남쪽을 설치하려고했고, 지금은 필요가 없습니다. 희망이 같은 상황에서 다른 사용자에게 유용한 헤드 - 최대를 제공합니다.

관련 문제