Feat/connect db #11
Feat/connect db #11
Conversation
report: Run #45
🎉 All tests passed! |
create_migration.sh
Outdated
| #!/bin/bash | ||
|
|
||
| if [ -z "$1" ]; then | ||
| echo "Usage: $0 <migration_name>" | ||
| exit 1 | ||
| fi | ||
|
|
||
| MIGRATION_NAME=$1 | ||
|
|
||
| atlas migrate diff "$MIGRATION_NAME" \ | ||
| --dir "file://ent/migrate/migrations" \ | ||
| --to "ent://ent/schema" \ | ||
| --dev-url "docker://postgres/15/test?search_path=public" |
There was a problem hiding this comment.
[의견] 쉘 스크립트도 폴더 하나에 몰아두면 어떨까요?!
There was a problem hiding this comment.
[대답] 좋아용!!! 안그래도 모아야할라나 고민이 있긴 했는데, 의견 같으면 그대로 모으는게 좋을 것 같네용 앞으로도 머가 또 생길 지 모르고 이미 3개나 되고
| @@ -0,0 +1,2 @@ | |||
| -- Create "companies" table | |||
| CREATE TABLE "companies" ("id" bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY, "create_time" timestamptz NOT NULL, "update_time" timestamptz NOT NULL, "name" character varying NOT NULL, "logo_url" character varying NOT NULL, "blog_url" character varying NOT NULL, "rss_url" character varying NOT NULL, PRIMARY KEY ("id")); | |||
There was a problem hiding this comment.
굳..이 고민되는건 soft delete 정도?! 있고 괜찮은 것 같슴당
사담 - auto increment가 mysql에서 쓰는 이름이었다는게 충격 그잡채입니다
There was a problem hiding this comment.
음 그러게 soft delete한번 고민해봐야겟네용
There was a problem hiding this comment.
추가해보았어용~~ㅋㅋㅋㅋ
공식문서 보고 그대로 적용했고,
확인하려면 ent go mixin, hook, interceptor에 대해서 확인을 해봐용... 설명 필요하면 나중에 따로 시간잡고 한번 설명해드리것습니다
사담 - sqlc로 그냥 슥슥 할껄... 차피 쿼리 잘 짤줄 아는데,,,ㅋㅋㅋㅋㅋㅋㅋㅋ
| @@ -0,0 +1,97 @@ | |||
| package config | |||
There was a problem hiding this comment.
저는 지금 config.go로도 괜찮은 것 같습니당
고랭 컨셉이 일단 짜고보는(?) 걸 지향하다보니
오히려 직관적이라는 생각이 드네용
config 개수가 늘어나거나(4~5개) 설정파일 뎁스가 늘어나면(config -> Aconfig -> BConfig 식으로 의존하게된다면) 그때 고민해봐도 좋을 것 같아요!
There was a problem hiding this comment.
ㅋㅋㅋㅋㅋㅋㅋ good good .
사실 만들면서 처음엔 자프링하듯이 디비랑 서버 config분리해서 만들다가 이게 맞나...? 하고 그냥 롤백하고 하나로 합쳐서 작업했슴다.
일단 그냥 만들기 말은 편한데 계속 이게 맞나 고미이 드면서 아직 어렵네용
report: Run #46
🎉 All tests passed! |
| urlField := func(name string) ent.Field { | ||
| return field.String(name). | ||
| GoType(&url.URL{}). | ||
| ValueScanner(field.BinaryValueScanner[*url.URL]{}) | ||
| } | ||
|
|
||
| return []ent.Field{ | ||
| field.String("name"), | ||
| urlField("logo_url"), | ||
| urlField("blog_url"), | ||
| urlField("rss_url"), | ||
| } |
There was a problem hiding this comment.
@iamjooon2 아 추가로 고민되는것...
여기서 url필드들을 객체로 꺼낼때 url.URL로 파싱해서 가져오도록 했는데, 이때 validation등이 될 수 있도록..
사실상 우리는 logo url, blog url등은 바로 클라이언트에 내려주는 용도로 사용되는거고,,, URL을 이용한 동작들이 많지는 않을것같아서.. 그냥 Company Struct에도 String으로 가지고 있게 해주는게 좋으려나 싶네
어케 생각하나용???
There was a problem hiding this comment.
entgo가 해주는 거라고 생각해서 db 스키마만 봤는데, schema 부분은 직접 만진 거였구만
난 큰 부분은 아닌 것 같아서 어느방향이든 괜춘!
report: Run #47
🎉 All tests passed! |
|
작업을 하다보니 커밋한다(대다수), 안한다(소수이긴 하지만) 모든 의견이 있지만, 일단 내 생각으론 커밋을 하고, 커밋메시지에 문제가 merge conflict가 생길 수 있다긴 한데,,, 이건 뭐 뒤에 머지시킬거에서 pull받고 해당 내용 포함해서 다시 generate하면서 해결하는거로 하면 될것같고 |
관련 이슈
close #8
변경 내용
요거 확인 부탁
파일 구조와 분리등을 어케하지 아직 감이 잘 안오네용..
ent관련은 문서대로 프레임워크에서 시키는대로 일단 진행했고,디비연결과 configuration쪽은 분리를 좀 했습니다.
이부분 어떤지나 한번 확인 부탁드려요...
company는 우선
필드를 모두 not null로 가지고 있긴 한데,, 이것도 더 필요할 필드나 아님 수정 필요한 부분 있을지 의견 주셔용
아직 운영디비 반영 X => 배포 전 테이블 생성 필요
(이부분도 스키마파일에 변동 생기면 자동으로 디비에 반영하라고 코멘트 남겨주는 워크플로우 나중에 하나 추가하면 좋것다)
우선 운영은 스키마 확인하고 쿼리 확인하면서 수동으로 마이그레이션 작업
로컬과 테스트디비의 경우 어케할지가 고민인데, 일단 여기에서 migrations내에 생성된 sql파일들은 지금으로선 사용하는게 아니라 버젼 기록용의 의미가 있게됨. 지금코드대로라면..
이유 : 지금은 local환경이면 ent에서 자동으로 디비 마이그래이션 작업 하도록 해둠 (spring의 ddl auto정도로 생각하면 될듯 우선)
그런데 이거를 atlas로 마이그래이션 관리하면 코드실행시 자동 마이그래이션이 아닌 atlas도구 사용해서 로컬에서 직접 마이그래이션 할 수 있도록 하는게 좋을까 고민이됨.
그렇게 되면 실제로 운영에 실행한 쿼리로 migrations들을 잘 관리하면서 좀 더 잘 관리가 될라나 싶은,,,
이거 내용 파악 위해서 ent에서 자동생성해서 실행되는 마이그래이션 쿼리와, atlas에서 자동생성하는 쿼리 차이가 있는지등 좀 더 확인하고 고민해볼 필요가 있을것 같긴 함
(이건 회의때 좀 더 자세히 이야기해봐용.. 노션에도 정리해둘께)
참고해야할 내용
ent하위파일은 기본적으로 자동생성되는 파일들이고,schema하위 파일에서 필요한 내용 수정 후 코드 generate진행atlas