기록하는 IT 블로그

🏕️상황 rds에서 테이블들을 확인해 보니 똑같은 테이블이 2개씩 대소문자만 살짝씩 바뀌어서 생겨있었다. 원인이 정확하게 뭔지는 모르지만 일단 확실한 건 rds(mysql)에서 테이블 명이든, 칼럼명이든 모든 소문자로만 저장한다는 것이다. 이 상태로 둘 순 없으니 그냥 스키마를 다 날리고 새로 만들었다. (안에는 더미 데이터만 있는 상태) 오른쪽 entity를 정의했고, @Column을 따로 지정하지 않았으니 해당 속성 명으로 db에도 생성되어야 하는데 rds에서 확인해 보니 맘대로 언더스코어를 붙이고, 모두 소문자로 바뀌어있었다. ⭐알아보니 로컬 Mysql 서버와 amazon rds mysql은 대소문자의 민감도가 달라서 내가 로컬에서 db를 활용했을 때 문제가 되지 않았던 부분이 rds에서는 문제가 ..

🏕️상황로컬에서 프로젝트 빌드, 컴파일 시에 전혀 오류가 없었다.로컬에서 각 기능들이 너무나 잘 돌아가는 것을 확인하였다.그 상태로 깃허브에 올리고 ec2에서 git pull 받고 빌드를 시키니 오류가 아래와 같이 100개가 나왔다 :) 💦과정이전 블로그에 올렸듯이 dev와 main 브랜치를 합치는 과정에서 많은 오류를 마주치고 해결하는 바람에 깃허브에 올린 코드가 아래의 사진처럼 2개씩 생긴 폴더나 파일이 있었다. (같은 폴더인데 구버전 : dto, 신버전 : DTO) 그래서 기뻤다. 왜냐? 이걸 고치면 오류가 100개씩이나 생기지 않을 것이라고 생각했다. 하지만 고쳐서 수정해도 달라지는 것은 없었다ㅎㅎ   🗝️해결오류가 100개가 아니라 10개라면 일일이 고칠 테지만 100개를 하나하나 고치는 ..

🏕️상황 dev 브랜치의 내용을 main 브랜치에 rebase를 하고 싶었는데 나의 착각으로 인해서 merge를 하게 되었다. 그런데 두 브랜치를 merge 한 지 꽤 되어서 충돌이 굉장히 많이 일어났다. 저 사진에 빨간 부분이 다 오류가 발생한 부분.... 🗝️과정 / 해결 일단 화면에 와 같은 충돌 마커를 다 제거하고, 충돌된 부분을 해결해도 빨간색이 사라지지 않는 클래스도 있었고.... 충돌 해결후에 git add 을 실행해도 unmerged 상태에서 statged 영역으로 내려가지 않고 계`~속 그 상태에 있는 파일이 있기도 했다. 🔜 그래서 일단 마지막까지 해결되지 않은 파일들은 지우고 나서 문제를 해결한 뒤에 다시 생성하기도 하고, 인터넷에서 보이는 것들을 여러 가지 시도하기도 하였다. 중간에..

🏕️상황 꽤나 긴 시간 동안 굉장히 여러 상황을 마주해서 하나하나 기억은 안 나지만 그래도 기억나는 거라도 작성해보록 하겠음. public void updateImages(List newImageList, List existingImageList) { // 새로 추가된 이미지 찾기 List addedImages = new ArrayList(newImageList); addedImages.removeAll(existingImageList); // 삭제된 이미지 찾기 List deletedImages = new ArrayList(existingImageList); deletedImages.removeAll(newImageList); // 새 이미지 업로드 로직 for (String newImage : add..

🏕️상황 처음에는 아래의 코드만 있으면 바로 삭제가 될 줄 알았다. public void deleteFile(String fileName) { DeleteObjectRequest request = new DeleteObjectRequest(bucket, fileName); amazonS3Client.deleteObject(request); } 그런데 나는 기존에 임시경로는 "temporary/"로 정식경로는 "final/"로 설정했기 때문에 이에 맞게 코드를 구성하려고 했다. 위의 코드는 루트 디렉터리 기준이고 나는 키(key) 구조를 활용해서 폴더 같은 형식으로 진행하고 싶었기 때문에 추가적인 코드 작업을 할 계획이었다. 하지만.... Amazon S3에서는 특정 폴더 내에 있는 파일을 삭제하기 위해 ..

🏕️상황 post men에서 post 방식으로 테스트를 진행하고 있었는데 계속 저런 오류가 발생하였다. + 🗝️해결 클라이언트 요청 헤더에 Content-Type을 올바르게 설정했는지 확인해야 합니다. 보내는 데이터의 형식에 따라서 Content-Type을 적절히 설정해야 합니다. 예를 들어 JSON 데이터를 보낼 때는 Content-Type을 application/json으로 설정해야 합니다.

> 게시글에 이미지를 올린다. 그럼 프런트 단에서 이벤트 감지 기능으로 api를 호출한다. (유효성 + 사이즈 검사를 진행 후 S3 임시 경로에 이미지들을 업로드한다.) 임시 경로가 포함된 해당 이미지의 URL을 반환한다. 사용자가 게시글까지 작성 후에 [등록하기]를 누르면 게시글은 게시글 DB에 저장, 이미지는 임시경로 🔜 정식경로로 이동시킨 후에 정식 경로로 변경된 url을 다시 반환받는다. public class imageService { @Autowired private AmazonS3 amazonS3; private final AmazonS3Client amazonS3Client; private final imageRepository repository; @Value("${cloud.aws.s3..

🏕️상황 > 나는 일단 하나의 api를 통해서 게시글의 내용들 + 이미지를 한 번에 처리하도록 구현하였다. 이미지를 포함한 게시판 기능을 계속해서 개발하던 중에 프런트 팀과 이야기를 나누게 되었는데 그 팀원의 의견은 다음과 같았다. 1. 예를 들어 사용자가 정상적인 이미지를 올리지 못하거나, 업로드에 실패했을 시에 하나의 api로 진행하게 되면 작성 중이던 게시글까지 날아가게 되니 사용자 입장에서 불편할 수 있는 상황이 생길 것이다. 2. api 분리를 하면 CDN을 이용해서 좀 더 빠르게 렌더링을 할 수 있을 것이다. 하지만 나는 아무리 생각해도 하나의 api로 처리를 하는 것이 괜히 일을 2번 만들지 않고 간단하게 진행하는 방법이라고 생각했기 때문에 생각이 좁혀지지 않았고, 결국 멘토분께 조언을 구하..

🏕️상황 간신히 [.gradlew build] 명령어를 통해서 빌드를 했는데 내가 원하는 건 막 요상한 그림이 나오면서 프로젝트가 '실행'되는 것인데 저렇게 build successful 이라는 글씨만 예쁘게 나오고 끝(?)나는 것이다...ㅠㅠ 원래 프로젝트가 실행되면 서버 엔드포인트를 호출 했을 때 요청에 대한 값이 나오는데 저렇게 502 오류가 발생. 🛣️과정 멘토분께 여쭤보니 굉장히 챙피한 일이었다... 개념 부족으로 인하여 당연한 일을 못한 것이다...ㅎ 🗝️해결 빌드하면 나오는 jar파일을 실행시키셔야죠 라고 하셨다!! 그래서 확인해보니 build를 하면 jar 파일이 생성되고, 그 파일을 java -jar 와 함께 실행시키면 된다. 💚./gradlew build Gradle은 프로젝트의 빌드,..

서버 api에 프로젝트 실행을 백드라운드로 돌려 서버 배포를 드디어 성공해서 post men에서 테스트 했을 때 해당 회원가입 내용이 성공적으로 RDS에 저장되었다!!