기록하는 IT 블로그

완전한 삭제가 아니라 반 삭제처럼 데이터를 일시적으로 비활성화하는 것을 "소프트 삭제(soft delete)" 또는 "논리적 삭제(logical delete)"라고 합니다. 소프트 삭제는 데이터를 데이터베이스에서 완전히 삭제하지 않고, 대신 삭제된 표시를 나타내는 특정 칼럼(예: "isDeleted")의 값을 변경하여 해당 데이터를 비활성화시킵니다. 이렇게 삭제된 표시를 가진 데이터는 일반적으로 조회 및 수정 작업에서 필터링되어 처리됩니다. 소프트 삭제는 데이터 복구 가능성이 있고, 삭제된 데이터의 이력을 추적할 수 있는 장점이 있습니다. 또한, 완전한 삭제보다 더 안전한 방법으로 데이터를 관리할 수 있습니다. 스프링 웹 프로젝트에서 소프트 삭제를 구현하기 위해서는 데이터베이스 스키마에 삭제 여부를 나타..

🛤️현상 public class Board { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; //이 오브젝트의 아이디 private String title; private String content; private Long category; @ManyToOne @JoinColumn(name = "userId") @JsonIgnore private User user; . . . } 이런 식으로 Board entity가 있는데 여기서 주목해야 할 부분은 user 필드이다. 이 필드의 자료형은 User라는 entity 클래스이다. 자료형을 객체로 지정하면 JPA가 알아서 그 객체의 pk를 가지고 온다고 한다. 그래서 user ..

⬇️리팩토링 전 코드 @RestController @CrossOrigin(origins = "http://localhost:3000", methods = {RequestMethod.OPTIONS, RequestMethod.DELETE, RequestMethod.GET, RequestMethod.POST, RequestMethod.PUT}) @RequestMapping("/review") public class ReviewController { private final ReviewService reviewService; public ReviewController(ReviewService reviewService) { this.reviewService = reviewService; } // 리뷰 등록 @Po..

🛤️현상 지금은 이렇게 원격 DB에 있는 테이블들이 인텔리제이 내부에서 보이지만 문제 해결 전에는 안 보였음ㅠㅠ 연결도 제대로 됐고, console창에서 sql문도 정상적으로 입력이 되는데 테이블들이 안 보였었음. (안 보였을 때 화면은 바빠서 캡쳐 못함) 🗝️해결 원래는 Name에 H2라고만 되어 있었는데 H2DB라고 바꾼다. 노란 박스에 있는 부분을 체크한다.

🛤️현상School entity의 id 값을 리뷰 entity의 schoolId가 외래키로써 사용하는 관계인데, 나는 왜 여기서 schoolId의 자료형이 왜 School인지가 의문이었다. 왜냐하면 DB에 들어있는 실제 schoolId의 자료형은 Long 타입인데 말이다. 그리고 저렇게 객체가 자료형이면 DB에는 어떻게 값이 들어가는지도 의문이었다.🗝️아하!왜 자료형이 School이지?[School 자료형을 사용함으로써 Review 엔티티와 관련된 School 엔티티와 직접적인 연관 관계를 설정할 수 있습니다. 이를 통해 Review 엔티티에서 관련된 School 객체에 직접적으로 접근하고 조작할 수 있습니다. Long 타입 대신 School 객체 자료형을 사용하는 이유는, 연관된 School 객체의..

🛤️현상 : @PostMapping("/save") public ResponseEntity save(Review review) { return ResponseEntity.ok().body(reviewService.save(review)); } 라고 메소드를 짯더니 포스트맨에서 테스트 했을 때 데이터가 들어오질 않았다. 🗝️원인/해결 : public ResponseEntity save(@RequestBody Review review) 이렇게 @RequestBody를 붙여야지 URL의 Value들을 받아올 수 있다.

🛤️현상 : 문제는 get은 CRUD 중에 read에서만 사용이 가능하다는 것이다. 근데 사실 내가 이제까지 공부하면서 get,post,put,delete의 차이를 진지하게 고민한적이 없다는 것이다. 근데 내가 개발을 crud 모두 성공했으나 모두 get으로 해버렸고 read 빼고는 다 바꿔야하는 상황인데 http메소드의 body에 데이터를 담아서 보내는 것을 처음 해봤다..... 포스트 맨에서 put방식으로 설정하고 쿼리파라미터 형식(키&밸류)으로 데이터를 넘기려고 하니까 { "timestamp": "2023-05-23T08:26:31.642+00:00", "status": 415, "error": "Unsupported Media Type", "path": "/review/update/3" } 이러한..

🛤️현상 : @PutMapping(value = "/update/{id}") public ResponseEntity update(@RequestBody ReviewDTO dto, @PathVariable Long id) { Optional reviewdto = this.reviewService.update(id, dto); logger.debug("------id값: "+id); return new ResponseEntity(reviewdto, HttpStatus.OK); } 라는 코드를 기반으로 http://localhost:8080/review/update?id=4&author=hhhhhhhhh&tags=IT&content=hello&trafficRate=4&facilityRate=4&cafeteri..

🛤️상황 나는 ReviewService - ReviewServiceImpl의 구조를 취했고, 팀원은 Impl 클래스를 없애고 거기에 있는 구현 코드를 controller에 작성하였다. 팀원이 그렇게 작성한 이유는 JPA를 사용하기 때문에 내가 직접 구현해야 하는 메서드들이 적다. service - impl 구조를 취하지 않는 것이 더 편리하다고 생각다. 지금 우리 프로젝트의 기능들이 그렇게 복잡한 구조를 요구하지 않는다. 하지만 나는 service - impl 구조로 프로젝트를 진행하고 싶었다. 그 이유는 다음과 같다. 그게 가장 노멀하고 정석적인 방법이라고 생각했다. 지금까지 공부한 책,블로그,강의 등에서 대부분은 그렇게 해왔다. 정석의 방식을 따르는게 나중에 탈이 없을 것이라고 생각했다. 🎢과정 팀원..

🌸상황위의 사진처럼 기능별로(controller, service ...) 폴더를 정리하지 않았었다. 팀원의 코드를 보니 기능별로 깔끔하게 정리를 해놓은 모습을 보게되었다.⭐앗차! 포인트팀원의 구성방식을 보니 파일들이 늘어날수록 저렇게 분류해놓지 않으면 나중에 파일을 일일이 찾는 것이 매우 번거로울 것 같다는 생각이 들었다.⛅향후방향왼쪽에 팀원의 폴더 정리 방식처럼 나의 코드도 리팩토링을 할 예정이며, 앞으로 다른 프로젝트에서도 제대로 적용시킬 생각이다.