해결된 질문
23.09.14 21:09 작성
·
641
·
수정됨
0
Entity를 변경하고 나서 서버 재 시동 시 Connection Error, Table {Table_name} already exist 에러가 발생하고, Entity와 상관없이 소스를 수정해도 여전히 동일한 에러가 발생합니다.
에러를 찾아봤는데도 명확한 해답을 찾지 못해 질문 드립니다.
[Nest] 1860 - 2023. 09. 14. 오후 10:13:42 ERROR [TypeOrmModule] Unable to connect to the database. Retrying (5)...
QueryFailedError: Table 'tb_user_info' already exists
변경 전
@Column()
@Field(() => String)
USR_USER_TYPE: boolean
변경 후
@Column()
@Field(() => Boolean)
USR_USER_TYPE: boolean
현재 Package는 아래와 같고요.
"@nestjs/typeorm": "^10.0.0",
"typeorm": "^0.3.17"
@Entity를 중복 선언하거나 소스가 두개이진 않습니다.
(기존에도 똑같은 질문이 있어서 확인했습니다.)
다만 Table명을 다르게 하기 위해 아래처럼 했습니다.
@Entity('TB_USER_INFO')
@ObjectType()
export class UserInfoEntity {
.....
이 에러를 찾아보니...
@Entity({ name: 'TB_USER_INFO', schema: 'user_schema'}) 처럼 하라고 하는데....
우선 제대로 된 해결법이 맞는지 궁금하고요.
만약 맞다면 저기서 얘기하는 schema가 무엇을 말하는지 못찾았습니다.
( 혹시 schema명이 database name이 아닌가 싶네요... 그렇게 했을때 별도로 다른 에러가 발생하진 않았거든요)
그리고 어떤 곳에선 synchronize를 false로 하고 직접 수정하는게 낫다는 사람들도 있더라고요.
조금 이해가 안되긴 하지만..... 해결됐습니다.
=============================================================
이런저런 테스트를 하다가 Stack overflow에서 어떤 사람이 @Entity작성 시 이름을 별도로 지정하지 않고 class명을 그대로 써서 해결됐다고 하길래 저도 그렇게 했더니 해결이 됐습니다.
최초 class명과 table명을 다르게 쓴 이유는 해당 entity클래스가 entity 라는걸 알아보기 쉽게 하려고 class에 entity라는 이름을 붙이고, table명에서는 entity를 쓰지 않았었습니다.
지금도 그렇게 하는 것이 더 편하다 생각하는데... 우선 에러를 해결하기 위해서는 이렇게 밖에 방법이 없네요;;;;;
혹시 테이블 명을 별도로 사용하고 에러가 나게 하지 않을 방법이 있을까요?
답변 2
0
2023. 09. 20. 11:06
안녕하세요! yisi님!
해당 문제는 버전 문제인 것 같아요!
아래 버전에서 동일한 테스트 결과 제대로 변경이 되며 충돌이 나지 않습니다!
"@nestjs/typeorm": "^9.0.1",
"typeorm": "^0.3.12",
"mysql2": "^3.2.0",
본 버전에서 테이블이름과 컬럼명을 아래와 같이 변경하였을 때, 정상적으로 작동이 됩니다
@Entity('TB_BOARD') => @Entity('TB_BOARD') // 변경없음
contents: string => contents: number // 변경됨
결과적으로, 버전 문제인 것 같네요!
(만약, 버전을 변경하고자 하신다면 yarn.lock과 node_modules를 삭제하고 다시 install 해주세요!)
다음으로 synchronize: false에 대해서 말씀드리면,
이 방법은 자동으로 동기화시키지 않고 직접 수정하는걸 말해요!
지금은 이걸 사용할 필요는 없습니다.
이러한 기능이 왜 있는가에 대해 설명드리면, 실제 배포가 이루어지고 나면 synchronize: false로 해주셔야 한답니다!
이유는 위에서 contents: string => contents: number로 변경하였을 때,
또는 contents: string => content: string (s를 삭제) 로 변경하였을 때 등. 컬럼의 수정이 일어나게 되면,
컴퓨터는 "아 contents가 content로 바꼈구나!" 라고 이해하지 못한답니다!
따라서, contents컬럼을 모두 삭제하고, 비어있는 content 컬럼을 생성하게 돼요!
그러므로, 데이터가 이미 들어간 실 배포환경의 DB에서는 synchronize: false로 두고 직접, 컬럼명만 SQL명령으로 변경시켜 사용하게 된답니다!^^
0
안녕하세요, 인프런 AI 인턴이에요.
TypeOrm의 “Table already exist” 에러는 이미 데이터베이스에 해당 테이블이 존재하기 때문에 발생합니다. 여러 가지 이유로 이 에러가 발생할 수 있으며, 일반적으로 다음과 같은 상황에서 발생할 수 있습니다.
문제를 해결하기 위해서는 다음과 같은 방법을 시도해 볼 수 있습니다.
테이블 확인: 데이터베이스에 해당 테이블이 이미 존재하는지 확인해보세요. 데이터베이스 클라이언트나 SQL 명령문을 사용해서 확인할 수 있어요.
Migration 확인: 데이터베이스 마이그레이션 파일이 제대로 작성되었는지 확인해보세요. 마이그레이션 파일에는 테이블 생성을 위한 쿼리문이 포함되어 있어야 해요.
연결 설정 확인: TypeOrm의 연결 설정 정보를 정확하게 입력했는지 확인해보세요. 특히, 데이터베이스 이름(database name)과 스키마(schema)가 일치하는지 확인해야 합니다.
에러 메시지에서 언급된 schema는 데이터베이스의 스키마를 의미합니다. 스키마는 데이터베이스 내에서 테이블을 구분하기 위해 사용되는 개념으로, 한 데이터베이스에는 여러 개의 스키마가 존재할 수 있습니다. 스키마명은 데이터베이스 이름과는 독립적이며, 테이블을 생성할 때 스키마를 지정하여 테이블을 구분할 수 있습니다.
에러 해결을 위해 위의 방법들을 시도해보시고, 문제가 계속되는 경우에는 좀더 구체적인 정보와 함께 질문해주시면 도움을 드릴 수 있을 것 같아요. 어떤 도움이 필요하신가요?
2023. 09. 20. 11:55
확인 감사드립니다.
많은 공부가 됐습니다. ^_^