📚 TIL 22일차

오늘의 주요사항 (6/15, 목요일)

1. 끝나지 않는 Spring의 굴레...
2. 개인과제 진행 (JPA 학습 전)

밤 늦게까지 보충학습 → 수면부족으로 아침운동을 못함
일찍 잠 → 진도가 살짝 늦어짐

딜레마인 듯!!

🌱 Spring Bean

[Spring] Spring Bean 등록과 사용

Spring 개인 과제

API 명세

마크다운으로는 표를 만들 수 없어서 스프레드 시트를 썼다는 슬픈 이야기가 있습니다...

DB 표준 시 설정

application.properties

mysql 주소가 잘 설정 되어있는지 확인할 것. 주소가 잘못 입력되어있으면 DB에 접속도 안 될 뿐더러 에러가 뜨기 때문에 sql 주소가 제대로 입력되어있는지 유의해서 살펴야한다.

spring.datasource.url=jdbc:mysql://localhost:3306/{DB명}?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Seoul

시간 설정: setTimestamp

참고: [JDBC] PrepareStatement에서 TimeStamp, LocalDateTime 사용하기

시간을 직접 입력해서 넣을 수는 없으므로, id처럼 시간이 자동으로 생성되도록 해줘야한다.

따로 생성하다보면 오차가 생길 수 있기 때문에 오차가 생기지 않도록 setCreatedAt와 setModifiedAt을 통해 현재 시간을 먼저 설정해주고, 값을 update할 때는 getCreatedAt와 getModifiedAt을 사용하여 설정된 값을 호출하도록 했다.

Timestamp는 매개변수로 LocalDateTime 값을 받기 때문에 .toLocalDateTime()을 사용해 값을 변환 후 전달해주었다.

BlogRepository.java

public Blog save(Blog blog) {

    // DB 저장
    // 기본 키를 반환받기 위한 객체
    KeyHolder keyHolder = new GeneratedKeyHolder();
    
    // 시간 설정
    blog.setCreatedAt(ZonedDateTime.now());
    blog.setModifiedAt(ZonedDateTime.now());
    
    String sql = "INSERT INTO post (createdAt, modifiedAt, title, content, author, password) VALUES (?,?,?,?,?,?)";
    
    jdbcTemplate.update(con -> {
    
        PreparedStatement preparedStatement = con.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS);
        preparedStatement.setTimestamp(1, java.sql.Timestamp.valueOf(blog.getCreatedAt().toLocalDateTime()));
        preparedStatement.setTimestamp(2, java.sql.Timestamp.valueOf(blog.getModifiedAt().toLocalDateTime()));
        preparedStatement.setString(3, blog.getTitle());
        preparedStatement.setString(4, blog.getContent());
        preparedStatement.setString(5, blog.getAuthor());
        preparedStatement.setString(6, blog.getPassword());
        
        return preparedStatement;
        
    }, keyHolder);

저장도 잘 된 것을 확인해 볼 수 있다!
수정했다!! (아래에 이어서)

날짜 타입에 대한 고찰

처음 Table을 생성할 때, 시간에 대한 데이터들(createdAt과 modifiedAt)의 타입은 DATETIME으로 지정했었다.

create table post (
        ...
		createdAt DATETIME not null,
		modifiedAt DATETIME not null,
		...
);

post 생성 직후 Response로부터는 날짜와 시간이 밀리초단위까지 출력됐지만, 바로 위의 이미지처럼 yy-mm-dd HH-mm-ss 형식으로 저장되기 때문에, Table 상으로는 자세한 확인이 불가능하다. 또, 데이터를 저장하고 불러올 때 계속 형변환을 해줘야하는 번거로움이 있다.

그래서 varchar 타입으로 저장하기로 결정했다.

create table post (
        ...
		createdAt varchar(100) not null,
		modifiedAt varchar(100) not null,
		...
);

varchar 타입으로 바뀜에 따라 작성했던 코드에도 변화가 조금 생긴다. 단순하게 LocalDateTime을 받아와 String 타입으로 변환해준다. (기존에 ZonedDateTime을 사용했었지만, 타임존이 표시될 필요까진 없어서 LocalDateTime을 사용하기로 했다.)

BlogRepository.java

public Blog save(Blog blog) {

    // ...
    
    // 시간 설정
    // 현재 시간을 받아서 String 타입으로 변환
    blog.setCreatedAt(LocalDateTime.now().toString());
    blog.setModifiedAt(LocalDateTime.now().toString());
    
   
   	// ...
   
    jdbcTemplate.update(con -> {
        PreparedStatement preparedStatement = con.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS);
        
        // 다른 데이터들처럼 getter를 사용한다.
        preparedStatement.setString(1, blog.getCreatedAt());
        preparedStatement.setString(2, blog.getModifiedAt());
        
        //...
        
        return preparedStatement;
        
    }, keyHolder);

작성 시간 기준 내림차순 정렬

내림차순 정렬을 해야한다는 조건이 있어서 정렬해주었다. 아래의 명령어를 이어서 붙여주기만 하면 간단하게 해결되었다.

## 내림차순 정렬할 때 사용하는 명령어
ORDER BY {정렬 기준 데이터 명} DESC

BlogRepository.java

public List<BlogResponseDto> findAll() {

	// DB 조회
    String sql = "SELECT * FROM post ORDER BY createdAt DESC";
    
    ...

비밀번호 받아서 판별하기

비밀번호를 받아와야하는데? 어떻게 받아오라고 제시되어있진 않았으나... 실행 테스트에는 Postman을 사용하고 있으니, 아마 @RequestBody를 사용해야하지 않을까! 라는 결론이 나왔다.

BlogController.java

// 선택한 게시글 수정
@PutMapping("/post/{id}")
public BlogResponseDto updateBlogPost(@PathVariable Integer id, @RequestBody BlogRequestDto requestDto) {

    return blogService.updateBlogPost(id, requestDto);
}

Controller는 비밀번호 값을 받기만 하고, 비밀번호를 판별하는 일은 Service에게 넘겼다. 사실 실제로 판별하는 일은 Repository가 하게 될 것이다.

BlogService.java

public BlogResponseDto updateBlogPost(Integer id, BlogRequestDto requestDto) {

    // 1. 해당 게시글이 DB에 존재하는지 확인
    Blog blog = blogRepository.findById(id);
    if(blog != null) {
    
        // 2. 존재하면 비밀번호를 체크
        boolean isRightPassword = blogRepository.checkByPassword(blog, requestDto.getPassword());
        if(isRightPassword) {
        
            // 3. 비밀번호가 옳으면 게시글 내용 수정
            blogRepository.update(id, requestDto); // DB 저장
            BlogResponseDto blogResponseDto = new BlogResponseDto(blog);
            
            return blogResponseDto;
            
        } else {
            throw new IllegalArgumentException("비밀번호가 올바르지 않습니다.");
        }
    } else {
        throw new IllegalArgumentException("선택한 게시글은 존재하지 않습니다.");
    }
}

Service는 Controller로부터 받은 정보를 사용해서 Repository에게 비밀번호를 판별하도록 지시한다.

// 2. 존재하면 비밀번호를 체크
boolean isRightPassword = blogRepository.checkByPassword(blog, requestDto.getPassword());

비밀번호는 String.equals(String) 메서드를 사용하여 판별하였다.

BlogRepository.java

// 비밀번호 체크
public boolean checkByPassword(Blog blog, String password) {

    // 비밀번호(문자열) 비교
    if (blog.getPassword().equals(password)) {
        return true;
        
    } else {
        return false;
    }
}

실행 결과

무사히 실행되었다!

삭제 성공 여부 Response하기

{
	"success":true
}

명세를 보면 이런게 있다. 뭐지? (보자마자 진짜 뭐지? 라고 생각함)

단순하게 true라는 값만 띄워줄 게 아니라, Dto를 통해서 반환해줘야한다고 생각했다. 그런데 기존에 사용하던 BlogResonpseDto 클래스를 반환하면 다른 값들도 같이 출력이 된다. 반대로 "success"라는 결과를 보여줄 필요가 없을 때도 보여지게 된다.

그래서 SuccessResponseDto라는 객체를 하나 더 만들기로 했다! 이름을 이미 설정한 상태에서 생각한 거지만, ResultResponseDto라는 이름이 더 적절했을지도 모르겠다...

SuccessResponseDto.java

@Getter
public class SuccessResponseDto {

    private Boolean success; // 저장 완료인지 아닌지
    
    public SuccessResponseDto(Boolean success) {
        this.success = success;
    }
}

이를 사용하기 위해서 연관된 클래스의 반환형을 SuccessResponseDto로 설정해주어야했다. 반환형이 바뀐 메서드는 BlogController.deleteBlogPost()와 BlogService.deleteBlogPost()이다.

BlogController.java

// 선택한 게시글 삭제
@DeleteMapping("/post/{id}")
public SuccessResponseDto deleteBlogPost(@PathVariable Integer id, @RequestBody BlogRequestDto requestDto) {

    return blogService.deleteBlogPost(id, requestDto);
}

BlogService.java

public SuccessResponseDto deleteBlogPost(Integer id, BlogRequestDto requestDto) {
    
    // 1. 해당 게시글이 DB에 존재하는지 확인
    Blog blog = blogRepository.findById(id);
    if (blog != null) {
    
        // 2. 존재하면 비밀번호를 체크
        boolean isRightPassword = blogRepository.checkByPassword(blog, requestDto.getPassword());
        if(isRightPassword) {
        
            // 3. 비밀번호가 옳으면 blog 삭제
            blogRepository.delete(id);
            
            // 4. Success 여부 반환
            return new SuccessResponseDto(true);
            
        } else {
            return new SuccessResponseDto(false);
        }
    } else {
        throw new IllegalArgumentException("선택한 게시글은 존재하지 않습니다.");
    }
}

BlogService.deleteBlogPost()의 경우는 비밀번호가 틀리면 false를 띄우는게 아니라, 아래처럼 오류를 던지려고 했었다. 현재 상태에서는 둘 중 뭐가 더 좋은지 모르고, api 명세에서는 "success"를 띄우라고 했기 때문에, 명세서를 더 우선해서 선택했다.

throw new IllegalArgumentException("잘못된 비밀번호 입니다.");

내일 할 일

1. JPA 및 남은 분량을 빛의 속도로 학습한다
2. 빛의 속도로 프로젝트에 적용한다
3. 운동!!