날짜, 시간별로 파일명이 생성된다는건 그렇게 관리 할 수 있다는 말과도 같다. 그러니 이를 어떻게 관리하는지 찾아보자. 내가 이상하게 생각하는건 django에서는 모델의 설정이 따로 있고 마이그레이션 파일이 있어서 모델의 컬럼설정을 자동으로 마이그레이션 파일로 생성해주었다. 그런데 라라벨에서는 모델과 마이그레이션 파일이 별도로 움직이는듯한 느낌을 받았다.
데이터베이스 스키마를 모두 마이그레이션에서 한다. 모델은 fillable이라 해서 사용자의 입력을 받는 곳을 지정한다. artisan으로 모델을 생성할 때 마이그레이션 파일도 같이 생성되고 이때 id, created_at, updated_at, user_id 같이 데이터의 관리를 위한 칼럼이 자동으로 추가된다.
그렇다면 마이그레이션을 이렇게 밖에 할 수 없을까? 뭔가 다른 방법이 있을거 같은데?
마이그레이션 방법
php artisan make:migration create_flights_table실행하면 현재일시로 기본상태(id, timestamp)만 가진체 마이그레이션 파일이 생성된다. 그런데 내가 원한건 현재상태(기존 칼럼을 그대로 가진)의 마이그레이션 파일이다. 좀더 알아보니 같은 테이블을 마이그레이션 하는데에는 좀더 신경써야할 부분들이 있었다.
최초에 테이블을 생성하면 위 그림과 같이 id와 timestamps가 생성된다. 그리고 내가 추가하고 싶은 칼럼을 추가한다. 이렇게 사용하다가 추가 칼럼이 필요하면 새로 마이그레이션을 생성한다. 그리고 나서 create가 아닌 “Schema::table(‘table_name’, function(Blueprint $table){” 형태로 해서 추가 칼럼을 등록한다.
이렇게 정확히 반대로 구성해야 마이그레이션과 롤백이 제대로 작동한다.
정리해보면
- command ./vendor/bin/sail php artisan make:migration new_table
- new_table.php의 create에 컬럼 추가
- 적용 command ./vendor/bin/sail php artisan migrate
- command ./vendor/bin/sail php artisan make:migration new_table
- new_table.php의 create를 table로 변경하고 변경할 컬럼을 추가
- 적용 command ./vendor/bin/sail php artisan migrate
./vendor/bin/sail php artisan migrate:fresh
이 코드를 실행하면 전체 테이블을 드롭하고 마이그레이션을 다시 실행한다.
./vendor/bin/sail php artisan migrate:refresh이건 전부 롤백 했다 마이그레이션을 다시 실행한다. 이 두 개는 현실에선 사용할 일은 없을거 같은데?
실제 운영에 마이그레이션을 써야 하겠지만 철저하게 코드화 하여 적용하지 않으면 큰일을 당할거 같다. 마이그레이션이야 그래도 문제가 없겠지만 롤백이 문제다.
디비를 보니 migration테이블이 있어 여기에 마이그레이션상태를 저장한다.
batch는 마이그레이션을 실행할 때마다 하나씩 올라간다. rollback하면 하나씩 내려가고.
오늘은 여기까지.
