오류 발생 시 처리 방법

migration 주변에서 오류가 자주 발생하기 때문에 매번 조사하기 때문에 필기 대신 여기에 두고 싶어요.

Mysql에 로그인

다음 명령은 기본입니다.

mysql -u ユーザー名 -D データベース名 -p

-u オプションでは MySQL に接続するユーザー名を指定します。
-D オプションでは接続先のデータベース名を指定します。
-p オプションはパスワードを送信する場合に指定します。

Mysql2::Error: Table 'hoges' already exists

분명히 그 테이블 이름이 있는데migration을 하면 오류가 발생할 수 있습니다.
'원하지 않아도 그런 기억이 없다'고 할 때 mysql에 로그인해서 테이블이 있는지 확인하세요.
다 보고 싶을 때.

show tables;

에서 지정한 테이블이 보고 싶을 때.

show columns from hoges;

테이블이 존재하지 않을 때 error가 되기 때문에 w가 있는지 확인할 수 있습니다
이미 존재한다면, 생성된 테이블 이름을 변경하십시오.

Index name 'index_hoge' on table 'homes' already exists

같은 이름의 index 이름이 있는 물건입니다.
테이블과 동시에 index가 붙어 있어서 이 오류가 발생하면 상당히 번거롭다.
우선 미그레이션이 어느 정도 진행되고 있는지 확인해 보자.그래서 mysql에 로그인합니다.다음 명령을 입력합니다.

mysql> select * from schema_migrations;

그러면

20150515072233
20150515072234
20150515102233

내가 보고 싶은 게 나왔어.
여기 있다.미그레이션을 좀 접촉해 볼게요.
schema_이른바 migrations
이것은 실행 중인 이전 스크립트를 기록하는 표입니다.
그렇다면 상술한 숫자 나열의 숫자는 어디에서 왔을까

rails generate migration hoges

때

db/migrate/20150515102233_create_hoges.rb

이렇게 할 수 있지만 이럴 때 덧붙인 숫자.
그래서 이번에 말하자면 2015/05/15에서migrate가 만든 파일도 읽을 수 있다.
본론으로 들어가다.이에 따라 2015051022233 이후에는 다시 읽지 못했다.
내가 만든 것은 201607210444829이기 때문에 읽지 않은 것을 안다.
다음은 다음 명령으로 테이블이 완성되었는지 확인하십시오.

show columns from hoges;

오류가 발생하지 않으면 존재합니다.
이제 index가 붙었는지 확인합니다.

show index from hoges;

이렇게 하면 볼 수 있다.존재하면 아래처럼 나올 거야.

오류가 발생했을 때의 열을 보고 index를 붙였는지 확인하십시오.
스티커가 없을 때... 처리 방법은 두 가지가 있어요.
① MySQL로 다시 쓰기
② 지우고 다시 한 번
① MySQL로 다시 쓰기
업데이트되지 않은 index를 MySQL, schema에 직접 쓰기파일 insert를migrations로 처리하는 방법입니다.

ALTER TABLE テーブル名 ADD INDEX インデックス名(カラム名);

테이블 이름이 hoges인 경우 색인을 추가할 수 있습니다.

ALTER TABLE hoges ADD INDEX index_hoges_on_updated_at(updated_at);

그 다음에 schema.insert migrations

INSERT INTO schema_migrations (version) VALUES(20160721044829);

그리고 결국 오류가 발생했다

db/migrate/20160721044829_create_hoges.rb

의 오류 부분이 수정되어 종료되었습니다.
② 지우고 다시 한 번
처리 과정을 거슬러 나아가다.
우선 index를 삭제합니다.

ALTER TABLE テーブル名 DROP INDEX インデックス名;

이런 규칙

ALTER TABLE hoges DROP INDEX index_hoges_on_updated_at;

색인을 삭제합니다.
그런 다음 테이블을 삭제합니다.

drop table hoges;

그리고 마지막으로migration이 끝납니다.
다만 이 경우 자신 이외의 migration 파일이 있다면 반대 절차를 밟지 않으면 오류가 발생할 수 있으므로 ①를 추천한다.
자신의 노트로서 오래됐지만 앞으로 무슨 일이 있어도 migration에는 문제가 없겠죠.