다른 DB를 사용할 때는 잘 사용하지 않던 스키마 개념 때문에 굉장히 혼란스러웠지만 이틀 정도 매대기치다보니 정리가 되었다. 휴 @.@


 

# 사용자 권한 설정과 스키마 설정

## postgresql 접속

psql postgres

 

### postgresql 명령어 참고 블로그

https://browndwarf.tistory.com/51

 

알아두면 유용한 psql 명령어 정리

PSQL 보통 PostgreSQL을 설치할 때 Client Tool인 pgAdmin이 같이 설치되고, 대부분 GUI 환경에서 pgAdmin을 사용하기 때문에 PSQL의 존재조차 모를 때가 있다. (필자는 PostgreSQL 처음 사용했을 때 psql의 존재를 1

browndwarf.tistory.com

 

- PostgreSQL 구조를 생각해두면 이해하는데 좋음

PostgreSQL DBMS > Database > Schema > Table & View & Procedure

 

## 현재 세션 유저 확인

postgres=# SELECT session_user;

 

## 사용자 생성

- 데이터베이스에 접속할 수 있는 사용자 역할을 생성

- testuser 라는 유저명, password 설정하여 유저 생성

postgres=# CREATE ROLE testuser WITH LOGIN PASSWORD '비밀번호설정';

 

## 데이터베이스 생성

- 데이터베이스 자체를 생성하며, 해당 데이터베이스의 소유자를 지정

create database testdb with owner testuser;

 

## 데이터베이스 목록 확인

postgres=# \l+

 

## testuser 계정으로 testdb 접속

postgres=# \c testdb testuser
접속정보: 데이터베이스="testdb", 사용자="testuser".
testdb=>

=> 는 superuser가 아님을 뜻함.

 

## 스키마 생성

PostgreSQL을 제일 먼저 설치하면, 기본적으로 postgres라는 database가 존재하는데 Public이라는 Schema가 생성됨.

그 외 testuser 유저명과 같은 이름의 testuser라는 스키마를 생성 

(사내 규정으로 동일한 이름으로 생성했지만, 필요에 따라 스키마명은 변경하면 된다.)

 

create schema testuser authorization testuser;

 

## 스키마 확인

testdb=> \dn+
                                          스키마 목록
   이름   |      소유주       |              액세스 권한               |          설명
----------+-------------------+----------------------------------------+------------------------
 public   | pg_database_owner | pg_database_owner=UC/pg_database_owner+| standard public schema
          |                   | =U/pg_database_owner                   |
 testuser | testuser          |                                        |

 

## 검색 경로 설정 (필요에 따라 설정하는 듯 싶다. 알아보고 추후에 다시 업데이트 하겠다.)

스키마를 사용자명과 동일하게 설정하지 않았을 때는 검색 경로를 설정해서 해당 DB에서 어떤 스키마가 검색될지 경로를 설정해야 한다.

스키마명을 사용자명과 동일하게 설정했다면 이 단계는 필요치 않다.

testdb=> set search_path to "$user",testdb;
SET
더보기

여기서 사용된 $user는 PostgreSQL에서 제공하는 특별한 변수로, 현재 세션에서 로그인한 사용자의 이름을 나타내게 된다.

이 변수를 사용하면 각 사용자마다 다른 검색 경로를 설정할 수 있다.

 

"$user": 현재 세션의 사용자 이름을 검색 경로의 첫 번째로 지정.

예를 들어, 만약 현재 세션이 testuser로 로그인되어 있다면, 검색 경로의 첫 번째는 testuser이다.

 

testdb: 데이터베이스 testdb를 검색 경로의 두 번째로 지정.

이는 명시적으로 데이터베이스 이름을 사용하여 검색 경로를 설정.

 

이렇게 검색 경로를 설정해두면 현재 사용자의 스키마(사용자의 이름과 일치하는 스키마)를 먼저 검색하고, 그 다음에는 testdb 데이터베이스의 객체들을 검색할 수 있다.

 

검색 경로를 설정함으로써, 객체를 참조할 때 스키마 이름을 명시하지 않고도 직접 참조할 수 있다.

## 사용자 권한 부여

-- testuser 스키마에 대해 testuser 사용자에게 모든 권한 부여
-- USAGE 권한을 부여하여 스키마 내의 객체에 접근할 수 있도록 함
GRANT USAGE ON SCHEMA testuser TO testuser;

-- testuser 사용자에게 testuser 스키마에서 테이블/시퀀스를 생성할 수 있는 권한 부여
GRANT CREATE ON SCHEMA testuser TO testuser;

-- 스키마 내의 모든 테이블에 대해 SELECT, INSERT, UPDATE, DELETE 권한 부여
-- 필요에 따라 권한 조정
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA testuser TO testuser;

-- 스키마 내의 모든 시퀀스에 대해 USAGE 권한을 부여
GRANT USAGE ON ALL SEQUENCES IN SCHEMA testuser TO testuser;

-- 스키마 내의 모든 함수에 대해 EXECUTE 권한 부여
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA testuser TO testuser;

 

 

# DBeaver를 통해 스키마 확인됨

- 디비버를 통해 스키마를 확인하려면 스키마에 할당해논 유저명과 비밀번호를 통해 연결하면 확인 가능.

이 포스팅에서는 사용자 생성에서 만든 testuser 유저로 연결하면 된다.

host는 로컬에서 돌리면 localhost, 가상 머신 위에 해당 DB를 설치했다면 가상 머신의 IPv4 주소를 확인해보길 !

 

 

 

 


참고 : https://velog.io/@easbui/PostgreSQL-%EC%8A%A4%ED%82%A4%EB%A7%88%EC%99%80-%EA%B6%8C%ED%95%9C

 

PostgreSQL 스키마와 권한

공부 기록 남기기지금까지 RDBMS 라고는 MYSQL과 그 사촌 MariaDB만 사용하다가, 이번에 PostgreSQL을 사용해 봐야겠다는 생각이 들어서 무턱 대고 설치해봤다. 일단 데이터베이스 생성과 유저 생성, 권

velog.io

https://kimdubi.github.io/postgresql/pg_schema/

 

PostgreSQL schema 의미 및 권한관리

MySQL이나 ORACLE 을 다루다가 PostgreSQL을 처음 다룰 때 가장 헷갈리는 것 중 하나는 바로 schema의 개념입니다. ORACLE에서는 오브젝트를 가진 USER, MySQL은 논리DB를 schema 라고 하는 반면에 PostgreSQL 에서

kimdubi.github.io

 

'DateBase > PostgreSQL' 카테고리의 다른 글

MacOS | homebrew 이용해서 postgresql 16 설치하기  (0) 2024.06.19

설치 환경 :

Mac M3 PRO / ITerm2 / Homebrew

---------------

Mac에 Homebrew가 설치되어 있다고 가정 후 진행.

설치 되어있지 않다면 아래의 명령어로 설치. 

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

 


# postgresql 16 설치

## 아래의 명령어로 postgresql 16 설치

brew install postgresql@16

 

## 환경 변수 추가

echo 'export PATH="/opt/homebrew/opt/postgresql@16/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
export LDFLAGS="-L/opt/homebrew/opt/postgresql@16/lib"
export CPPFLAGS="-I/opt/homebrew/opt/postgresql@16/include"

 

## 서비스 시작

brew services start postgresql@16

 

## 서비스 구동 확인

brew services status postgresql@16

 

## 설치된 postgresql 버전 확인

postgres --version

 

 

설치 끝!


 

# postgresql 접속

psql postgres

 

### postgresql 명령어 참고하기 좋은 블로그 소개

https://browndwarf.tistory.com/51

 

 

사용자 권한 설정과 스키마 설정에 대해서는 다음의 포스팅을 확인해주세요.

https://mangocoding-journal.tistory.com/43

 


참고 : https://kholo.dev/post/how-to-install-postgresql-on-mac

 

Mac에서 Homebrew를 이용해 Postgresql 를 설치하기 - 콜로리 블로그

다양한 개발 이야기와 경제 관련 인사이트를 다루는 블로그.

kholo.dev

 

 

본인은 구글 클라우드를 사용하였다.

 

사용자 인증 정보 클라이언트를 생성 후

 

  • access_type : offline (access token 새로고침)
  • response_type : 반환할것
  • redirect_uri : OAuth 클라이언트 ID를 생성할때 입력한 승인된 리디렉션 URI를 urlencode 한 것
  • client_id : OAuth 클라이언트 ID를 생성하고 발급받은 클라이언트 ID

---

code를 복사해놓자

TalendAPI(Postman)에서 POST방식으로 https://oauth2.googleapis.com/token 해당 uri로

BODY에 code, client_id, client_secret, grant_type를 담아 다음과 같이

code=4/0AdLIrYclWNNOQQddLIrYcQduYcQdudLlWNIrYcQdudLIrYcQdulWNNOQ
&client_id=1065376047615-ca8n7aacvn2ve5jwn33ckfh1hsv99.apps.googleusercontent.com
&client_secret=GOBJKB-HOFEUMtPMsdil82ORlQLkTOgprYz
&redirect_uri=http://localhost:8080/authcode
&grant_type=authorization_code

요청을 보내면 된다.



참고 자료:

https://cloud.google.com/apigee/docs/api-platform/security/oauth/access-tokens?hl=ko#requestinganauthorizationcode

 

OAuth 2.0 토큰 가져오기  |  Apigee  |  Google Cloud

Apigee API로 OAuth 액세스 토큰 및 승인 코드를 가져오는 방법과 Apigee OAuthV2 정책을 만들고 프록시 엔드포인트를 구성하는 방법을 알아봅니다.

cloud.google.com

https://soda-dev.tistory.com/60

 

[API] 구글 OAuth로 토큰(access token) 발급받기

구글 클라우드 플랫폼을 사용하여 연동한다. OAuth토큰 사용 포스트맨 (Postman) 사용 구글 클라우드 플랫폼 https://console.cloud.google.com/ Google Cloud Platform 하나의 계정으로 모든 Google 서비스를 Google Clou

soda-dev.tistory.com

https://ahn3330.tistory.com/166

 

[OAuth] HTTP 통신으로 구글 auth token 발급 및 구글 api 사용하기

OAuth 개념이 어려운데, 구글을 예시로 간단하게 말하면1. 사용자에게 권한 요청 및 동의를 받는다. 그러면 authrization code를 획득한다.2. authorization code를 가지고 구글에게 access token을 요청한다.3.

ahn3330.tistory.com

 

 

'Java > Spring Boot' 카테고리의 다른 글

[Thymeleaf] 문법  (0) 2023.09.21
Lombok | @Builder 동작 원리  (0) 2023.09.21
[API 작성법] GET API 만드는 법 핵심 정리  (0) 2023.09.14

build.gradle의 dependencies에 다음 코드를 추가해주고 reload 시켜주면 

//JUnit4 추가
testImplementation("org.junit.vintage:junit-vintage-engine") {
    exclude group: "org.hamcrest", module: "hamcrest-core"
}

 

import org.junit.runner.RunWith;

import문이 잘 먹힌다. 해결!

 

참고로 junit5는 @RunWith(SpringRunner.class)이 아닌 @ExtendWith(SpringExtension.class)를 사용한다고 한다.

 

 


참고한 블로그

: https://velog.io/@hyeon030/Junit5-RunWithSpringRunner.class

 

팀장이나 스크럼마스터가 프로젝트 환경 설정 후 github에 올리면 나는 로컬에 가져와야 한다.

 

어떻게? git clone으로.


git bash 열어서 폴더 만들 위치에서

git clone <레포지토리 http 주소>

 

 

 

그리고 브랜치도 clone해오자

 

## 방법 1

checkout이 하나의 명령어 안에 여러 기능을 가지고 있어서 이제는 checkout을 사용하지 않는다고 한다.

이 방법은 지양하자.

git checkout -t origin/브랜치명

 

## 방법2

### switch로 브랜치 변경

git switch -c 브랜치명

 

-c 는 그 브랜치가 없으면 생성해달라는 명령어

 

### 원격 브랜치 pull 해오기

git pull origin 브랜치명

 

그 안에 파일들이 안보이면 reload해보면 뜬다.

아주 오랜만이다. 드디어 내가 수강하는 부트캠프에서도 final 프로젝트에 접어들었다.

[1주차 - 팀 빌딩 & 아이디어 회의 & 개발 환경 논의]
3주전 쯤 팀 구성을 하고 프로젝트 주제를 위한 아이디어 회의를 통해 1. 헬스 케어 2. 새로운 지역에서의 맛집 추천과 음식점 예약&웨이팅 3. 채용 사이트 등등 다양한 의견이 나왔고 팀원들과의 열띤 토론 끝에 기존 채용 사이트에서 불편한 점들을 개선한 웹사이트를 구현해보기로 했다. 개발 환경 및 스택은 intellij, gradle, Thymeleaf, bootstrap, mysql, spring Cloud, Docker, kubernates, AWS.. 로 정했다. 프론트에 큰 힘을 쏟고 싶지 않아서 react보다는 타임리프를 선택했고 DB는 가장 편한 mysql이나 maria를 사용하고 싶었다.

 

[2주차 - 화면 및 기능 설계]

아직 수업이 한 달 정도 남아있기 때문에 수업이 끝나고부터 센터가 닫는 9시반까지 매일 팀원들과 회의를 한 것 같다.
우리가 Client가 되어 어떤 화면이 필요하고 이 버튼을 클릭했을 때는 어떻게 넘어가고 어떤 데이터들이 불러와져야 한다. 지원자 입장에서는 지원한 공고마다 제출한 자소서나 이력서들을 확인 할 수 있으면 좋겠다. 면접 질문에 대해서도 관리할 수 있는 페이지가 있으면 좋겠다. 등등 서로 의견을 제시하면서 이건 아닌 것 같아요. 이게 더 낫지 않을까요. 그 의견 좋은거 같아요. 가감 없이 의견을 나누면서 필요한 기능과 페이지들을 설계했다. 회의를 하면서 간단간단하게 글로 적혀있어 구현할 때 화면이 있으면 좋겠다는 의견이 있었고 다들 동의해서 어떤 페이지에 어떤 데이터들이 어느 위치에 들어가야 한다 정도로만 잡아두자는 취지에서 figma를 이용해 화면 설계 및 디자인을 완료했다. 중간에 다들 과열되는 양상이 있었지만 곧 바로 다들 정신차리고 여기에 너무 힘을 쏟지 말자라고 의견이 정리되어 다행히 많은 시간을 소비하지 않았다.

 

[3주차 - ERD 설계 & MSA 프로젝트]

ERD 설계를 위해 서비스 별로 나누자는 의견이 나왔고 처음에는 서비스를 어떤 기준으로 나눠야 할 지도 애매하고 팀원들끼리도 이게 맞는 것 같다. 저게 맞는 것 같다. 얘기를 나누다 ERD 작성 전에 화면 설계한 것을 보면서 데이터들을 뽑아내서 엑셀에 정리하면서 이건 따로 테이블로 빼는 게 맞는 거 같다. 이건 너무 공통적으로 들어가는 데 이런건 하나의 테이블로 두는 게 나을 것 같다. 등등 의견이 나오면서 자연스레 데이터 타입, 속성까지 정리하게 되고 DB와 맵핑할 엔티티들도 함께 정리하게 되었고 그걸 바탕으로 팀원 중 한분이 맡아서 ERD 설계를 완성해주셨다. 참고로 ERD 설계 툴은 erdCloud를 사용했다. 팀원 중 한 분이 복사본을 지운다는 걸 최신 버전을 지워버려서 아찔할 뻔 했던 순간도 있었지만 다행히 우리 팀에는 인간 데이터베이스라고 불리우는 다른 한 분이 스냅샷을 찍어 두신 게 있어서 그걸 토대로 다같이 빠르게 복구시켰다. 그 뒤로는 권한에 대한 경각심이 생겨서 ERD, Github 다 권한을 제한하도록 했다. 이런 헤프닝이 프로젝트 초창기에 일어나서 너무 다행이였다. 오히려 가벼운 일을 통해 경각심을 갖게 되어 더 큰 사고를 방지할 수 있던 것 같다. 그리고 팀원들이 화면 디자인을 할 동안 ERD를 완성해주신 팀원분께서 엔티티와 sql문까지도 완성해주셨다.
> issue
간과한 것이 있었다. 지금까지 진행해온 프로젝트들은 다 모놀리스 방식이였다. MSA 방식으로 구현할 지 모놀리스 방식으로 구현할 지 논의가 되지 않았던 것이다. 아차차... 프로젝트의 근간을 흔들 수 있는 걸 이제야 깨닫게 된 것이다. 하지만 이 때까지만 해도 MSA에 대한 이해도 부족했고 도커도 얼마 배우지 않아 내부적으로는 이때라도 깨달은 게 다행이고 오히려 일찍 깨달은 것일 수도 있다고 판단했다. 아무튼 팀원들과 얘기를 해 본 결과 final 프로젝트이기도 하고 부트캠프 과정이 '대용량 서비스를 위한 MSA 엔지니어 양성 과정' 이니 만큼 MSA 방식으로 프로젝트를 진행하자는 쪽으로 의견이 좁혀졌고 ERD를 대폭 수정하게 되었다. FK로 얼기설기 꼬여있던 테이블들을 서비스를 기준으로 별로 분류하여 회원서비스, 주소 서비스, 관리자 서비스, 공고 서비스, 마이페이지 서비스, 지원서 서비스, 문의 서비스 이렇게 Micro service가 7개가 탄생하였다.  

 

[4주차 - 멘토링&애자일도입]
해당 주차에는 API 명세를 작성하기로 하였고 API 명세서를 작성하는 방법에 대해 논의를 하고 있던 찰나 멘토님이 지정되었고 그 날 바로 연락이 와서 바로 미팅이 괜찮냐고 하셔서 멘토링을 다른 팀들보다 빠르게 시작하게 되었다.

+) 멘토님이 각자 자기소개 해달라고 하셔서 json 형태로 자기소개했다ㅋㅋ 

첫 번째 멘토링에서 애자일에 대해 가르쳐주셨다. 그 전에 팀 회의에서도 애자일로 프로젝트를 진행하는 게 좋을 것 같다는 얘기가 나왔었지만 애자일에 대해 완벽히 이해하고 있던 팀원들은 없었다. waterfall과 애자일 방법론을 알려주셨고 설명을 듣고 나니 우리 프로젝트처럼 규모가 큰 프로젝트는 더욱이 필요하다고 생각했다. 메인 기능 개발을 위주로 sprint를 돌려가며 개발하고 우선순위가 후 순위인 기능들은 후반부 sprint에서 develop하면서 프로젝트를 진행하기로 하였다. 
멘토링이 끝난 후 우리의 프로젝트에서 핵심 메인 기능은 유저가 공고를 지원하는 것이라고 정했고 첫 번째 sprint는 유저가 공고를 지원하기 위해 필요한 요소들로 잡았다. 그렇다면 자연스레 회원가입, 로그인, [기업] 공고 올리기, [유저]공고 목록보기, [유저] 공고 상세보기가 메인 기능으로 잡혀졌고 해당하는 뷰를 담당을 정해서 백로그를 작성 후 sprint planning meeting 을 진행하였다. 백로그 작성은 깃허브 project의 번트차트를 이용하였고 백로그 작성이 처음이다보니 헷갈리는 부분이 많았다. 처음에는 DOD 작성이나 스토리포인트를 어떻게 정해야 할 지가 막막했다. 하지만 하다보니 오히려 놓칠 뻔 했던 부분들을 다잡는 시간이 된 거 같다.

하고 멘토링  한 번 더 했고 API나 기능 구현에 대한 피드백을 받았고

DOD를 구현 방법까지 너무 디테일하게 들어가서 백로그 작성하는데 삽질했고 
팀장님이 바로 잡았고 환경 세팅 후 개발 시작할 수 있게 되었다...

 

[지금 시점에서의 회고..]
팀원들이 다들 열정적인 분들이라 의견도 자유롭게 내고 다양한 의견들이 오가는 것 같다. 혼자 프로젝트를 할 때는 느낄 수 없었던.. 팀원들이 있어 가장 좋은 점은 삽질하지 않아도 된다는 점. 혼자 프로젝트를 진행할 때는 내가 생각하고 내가 결론을 내리니 잘못된 방향으로 가도 바로 잡아줄 사람이 없어 뒤늦게 깨닫는 경우들이 많은데 서로 지식 공유나 구현 방법에 대해서 얘기하다보면 바로 바로 피드백이 들어오기 때문에 시간이 단축된다는 점이 협업의 큰 메리트라고 생각한다. 또, 내가 생각한 설계, 구현 방법보다 더 효율적이고 좋은 아이디어가 넘친다는 것. 나 혼자 프로젝트를 했으면 비슷한 결과물 , 비슷한 코드가 구현되겠지만 다양한 의견이 오가면서 더 좋은 의견을 흡수하게 된다. 그리고 무엇보다 우리 팀이 마음에 드는 건 대화법이다. 서로 아닌 것 같거나 불만이 있는 점은 꿍해있지 않고 바로 바로 얘기를 함으로써 그 상황에서 서로 충분히 얘기를 하고 모르거나 이해 안되는 부분들도 서로 서로 솔직히 물어보고 채워주며 보완해나가고 있다. 팀원들이 한 분 한 분 다 배울 점이 있는 분들이라 너무 좋다. 그 분들의 장점이 나의 장점이 될 수 있도록 받아들이고 더 노력해야 겠다. 

 

+ Recent posts