당신이 말하는 것은 잘 알려져 있고 상당히 복잡한 문제입니다. 이를 데이터베이스 이주라고합니다. 모든 훌륭한 프로젝트에는 한 제품 버전에서 다른 버전으로 이전하기 위해 데이터베이스 스키마와 데이터 변형을 적용하는 방법을 설명하는 정책이 있습니다.
Django 또는 Ruby on Rails와 같은 많은 프레임 워크에는 플러그인으로 기본 제공되거나 사용할 수있는 이전 시스템이 있습니다. SQLAlchemy를 사용하는 경우 몇 가지 옵션이 있습니다.
- 시스템을 사용하지 마십시오. 손으로
/tmp/migrate.sql
을 작성하고 ALTER/DROP/CREATE 문을 기록하고 손가락을 교차시켜 SQLite 기본에 적용하십시오. 오류가 발생하기 쉽기 때문에 일반적으로 나쁜 생각이지만 선택은 당신에게 달려 있습니다. 완전한 기능을 갖춘 ALTER TABLE
구문의 부재는 임시 이름으로 원하는 속성으로 새 열을 생성하고 원래 열의 모든 데이터를 복사 한 다음 원래 열을 제거하고 새 열의 이름을 원래 이름으로 변경하여 해결할 수 있습니다. 동일한 기술이 테이블 수준에서 사용될 수 있습니다.
- liquibase과 같은 타사 이전 시스템을 사용하십시오. Liquibase는 단점을 제외하고는 멋지고, 잘 설계되어 있으며 강력합니다. 그것은 정말 버그입니다. 나는 SQLite (그리고 SQLAlchemy에 대해서는 그렇다. 그러나 실제로는 중요하지 않다)를 시도해 보았고, 꽤 기본적인 것들을하지 못했다. 나는 문제를 찾아 봤는데 그들이 알려진 버그라는 것을 알았다.
- 앞서 언급 한 SQLAlchemy-migrate를 사용하십시오. 그것은 영감을 얻은 ROR 마이그레이션만큼 강력하지도 않으며 liquibase만큼 강력하지도 않지만 작동합니다. SQLite 제한은 같은 방식으로 해결 될 수 있습니다.
그리고 열을 삭제하려고하면 SQLAlchemy-migrate가 수행 할 작업에 대해 질문했습니다. 글쎄, 그것은 칼럼을 삭제할 것이고 그 칼럼에 있던 모든 데이터를 삭제할 것이다. 표의 다른 열은 그대로 유지됩니다.