Django에서 데이터베이스 테이블 변경

Django에서 데이터베이스 테이블 변경

---

내가 시작하는 프로젝트 (fyi, 브라우저 기반 게임)에 Django 사용을 고려하고 있으며 내가 가장 좋아하는 기능 중 하나는 syncdb내가 정의한 Django 모델을 기반으로 데이터베이스 테이블을 자동으로 생성하는 것입니다 (a 다른 프레임 워크에서 찾을 수없는 기능). 나는 이미 문서 에서 이것을 보았을 때 이것이 사실이라고 생각하기에는 너무 좋다고 생각했습니다 .

Syncdb는 기존 테이블을 변경하지 않습니다.

syncdb는 아직 설치되지 않은 모델에 대해서만 테이블을 생성합니다. 설치 후 모델 클래스에 대한 변경 사항을 일치시키기 위해 ALTER TABLE 문을 실행하지 않습니다. 모델 클래스와 데이터베이스 스키마의 변경에는 종종 어떤 형태의 모호성이 포함되며, 이러한 경우 Django는 올바른 변경을 추측해야합니다. 프로세스에서 중요한 데이터가 손실 될 위험이 있습니다.

모델을 변경하고 일치하도록 데이터베이스 테이블을 변경하려면 sql 명령을 사용하여 새 SQL 구조를 표시하고 기존 테이블 스키마와 비교하여 변경 사항을 해결하십시오.

기존 테이블 변경은 "수작업"으로 이루어져야 할 것 같습니다.

제가 알고 싶은 것은이를 수행하는 가장 좋은 방법입니다. 두 가지 해결책이 떠 오릅니다.

• 문서에서 알 수 있듯이 DB에서 수동으로 변경하십시오.
• 데이터베이스를 백업하고, 지우고, 테이블을 다시 생성하고 (syncdb를 사용하여 지금은 처음부터 테이블을 생성하기 때문에) 백업 된 데이터를 가져옵니다 (데이터베이스가 큰 경우 시간이 너무 오래 걸릴 수 있음).

어떤 아이디어?

---

동일한 주제에 대한 다른 답변에서 언급했듯이 YouTube 에서 DjangoCon 2008 Schema Evolution Panel 을 시청하십시오 .

또한 맵에있는 두 개의 새로운 프로젝트 : Simplemigrations 및 Migratory .

---

수동으로 SQL 변경 및 덤프 / 다시로드를 수행하는 것은 둘 다 옵션이지만 Django 용 스키마 진화 패키지 중 일부를 확인하고 싶을 수도 있습니다. 가장 성숙한 옵션은 django-evolution 및 South 입니다.

편집 : 그리고 이봐, 여기 dmigrations 가 온다 .

업데이트 :이 답변이 원래 작성 되었으므로 django-evolution 과 dmigrations 는 모두 활발한 개발을 중단했으며 South 는 Django에서 스키마 마이그레이션의 사실상 표준이되었습니다. South의 일부는 다음 릴리스에서 Django에 통합 될 수도 있습니다.

업데이트 : South를 기반으로 한 스키마 마이그레이션 프레임 워크 (그리고 South의 저자 인 Andrew Godwin이 작성 함)가 Django 1.7+에 포함되어 있습니다.

---

이를 수행하는 한 가지 좋은 방법은 조명기, 특히 initial_data조명기를 사용하는 것입니다.

고정 장치는 데이터베이스의 직렬화 된 내용을 포함하는 파일 모음입니다. 따라서 데이터베이스를 백업하는 것과 비슷하지만 Django는 사용하기가 더 쉽고 단위 테스트와 같은 작업을 수행 할 때 추가 이점이 있음을 알고 있습니다.

을 사용하여 현재 DB에있는 데이터에서 조명기를 만들 수 있습니다 django-admin.py dumpdata. 기본적으로 데이터는 JSON 형식이지만 XML과 같은 다른 옵션을 사용할 수 있습니다. 조명기를 저장하기에 좋은 장소는 fixtures애플리케이션 디렉토리의 하위 디렉토리입니다.

을 사용하여 픽스처를로드 할 수 django-admin.py loaddata있지만, 픽스처가 initial_data.json를 수행 할 때 자동으로로드되는 것과 같은 이름이 조명기 인 경우 syncdb직접 가져 오는 수고를 덜어줍니다.

또 다른 이점은 manage.py test단위 테스트를 실행하기 위해 실행할 때 임시 테스트 데이터베이스에도 초기 데이터 고정 장치가로드된다는 것입니다.

물론 이것은 모델에 속성을 추가하고 DB에 열을 추가 할 때 작동합니다. 데이터베이스에서 열을 삭제하면 간단하지 않을 수있는 해당 열에 대한 데이터를 제거하기 위해 조명기를 업데이트해야합니다.

이것은 개발 중에 많은 작은 데이터베이스 변경을 수행 할 때 가장 잘 작동합니다. 프로덕션 DB 업데이트의 경우 수동으로 생성 된 SQL 스크립트가 가장 잘 작동하는 경우가 많습니다.

---

나는 django-evolution을 사용하고 있습니다. 주의 사항은 다음과 같습니다.

• 자동 제안은 한결같이 썩었습니다. 과
• 지문 기능은 다른 플랫폼에서 동일한 데이터베이스에 대해 다른 값을 반환합니다.

즉, 사용자 지정 schema_evolution.py접근 방식이 편리합니다. 지문 문제를 해결하려면 다음과 같은 코드를 제안합니다.

BEFORE = 'fv1:-436177719' # first fingerprint
BEFORE64 = 'fv1:-108578349625146375' # same, but on 64-bit Linux
AFTER = 'fv1:-2132605944' 
AFTER64 = 'fv1:-3559032165562222486'

fingerprints = [
    BEFORE, AFTER,
    BEFORE64, AFTER64,
    ]

CHANGESQL = """
    /* put your SQL code to make the changes here */
    """

evolutions = [
    ((BEFORE, AFTER), CHANGESQL),
    ((BEFORE64, AFTER64), CHANGESQL)
    ]

더 많은 지문과 변화가 있다면 리팩토링 할 것입니다. 그때까지 깔끔하게 만드는 것은 다른 것에서 개발 시간을 빼앗는 것입니다.

편집 : 어쨌든 수동으로 변경 사항을 구성하고 있다는 점을 감안할 때 다음 번에 dmigrations를 시도 합니다.

---

django-command-extensions 는 manage.py에 몇 가지 추가 명령을 제공하는 django 라이브러리입니다. 그중 하나는 sqldiff로, 새 모델로 업데이트하는 데 필요한 SQL을 제공합니다. 그러나 그것은 '매우 실험적'으로 나열됩니다.

---

지금까지 우리 회사에서는 수동 접근 방식을 사용했습니다. 자신에게 가장 적합한 것은 개발 스타일에 따라 크게 달라집니다.

We generally have not so many schema changes in production systems and somewhat formalized rollouts from development to production servers. Whenever we roll out (10-20 times a year) we do a fill diff of the current and the upcoming production branch reviewing all the code and noting what has to be changed on the production server. The required changes might be additional dependencies, changes to the settings file and changes to the database.

This works very well for us. Having it all automated is a niche vision but to difficult for us - maybe we could manage migrations but we still would need to handle additional library, server, whatever dependencies.

---

Django 1.7 (currently in development) is adding native support for schema migration with manage.py migrate and manage.py makemigrations (migrate deprecates syncdb).

참고URL : https://stackoverflow.com/questions/35991/altering-database-tables-in-django