학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. [질문 내용] 강의보고 책으로 복습하다가 궁금한 점이 있어서 질문드립니다. jpa 책 105쪽에 변경감지에 관한 내용입니다. 엔티티가 영속성 컨텍스트에 보관될 때 최초의 상태(persist())를 스냅샷으로 저장해두고 플러시 시점의 엔티티를 비교해서 변경사항에 대한 수정 쿼리를 쓰기지연 sql 저장소에 보낸다고 되어있습니다. 이 메커니즘은 이해가 되는데 persist(); setName(); flush(); 여기서 persist()를 하게 되면 실제 db에 바로 반영이 되는 것이 아니라 영속 컨텍스트에 저장(1차캐시), 이후 insert 쿼리를 쓰기 지연 저장소에 저장하게 됩니다. 이후 엔티티의 이름을 변경하고 플러시할 경우 스냅샷과 플러시 시점의 엔티티 상태를 비교해서 변경 부분에 관한 수정 쿼리를 쓰기지연저장소에 보낼 때 쓰기지연저장소에는 insert와 update 두 쿼리가 있고 플러시할 때 insert, update 두가지 모두 실행되는 걸까요? 아니라면 이유가 궁금합니다! 찾아보니까 insert만 나간다고 하는데 왜 그런지 도무지 이해가 안됩니다.
왼쪽 코드 맨아래 설명을 생략하신거 같은데요 NULL은 숫자 0이 아니잖아요 그래서 NULL==0은 거짓이니까 0이라고 생각했습니다 그래서 저는 출력 시 NULL==0의 결과: 0 이라고 생각했거든요 그런데 오른쪽 출력값에 1이라고 나와있더라구요 오타인가요? 아니면 제가 이해를 잘 못한건가요??
현재 경력 기술서는 큰돌님이 말씀하신 것과 비슷하게 하나의 이슈에 대한 문제, 분석, 해결 과정, 결론 및 소감 형태로 나열되어 있습니다. 여기서 문제점이, 이슈가 많을수록, 내용이 많을수록 비대해지더라구요.. 한, 두 줄 내로 줄여도 이슈가 많으니 페이지는 자꾸 늘어나고 있습니다. 경력기술서 내용을 포트폴리오에 넣어 분산시켜야 할지, 굵직한 이슈만 적어야할지, 방향에 대해 고민이 됩니다. 경력기술서의 존재 이유?(면접관이 왜 보는지, 어떤 부분을 중심으로 보는지 등) 같은게 궁금합니다.
업캐스팅 문제 예시 5번문제와 6번 문제 질의입니다. 5번 문제에서 최초 A b = new B(1) 에서 부모 기본생성자를 방문하므로 "생성자 of A" 출력 그다음으로 자식 기본생성자를 방문하므로 "생성자 BB1" 출력 3. 그러나 6번 문제에서는 최초 A b = new B(1) 로 5번 문제와 동일한 형태의 생성자가 존재하지만 부모의 기본 생성자인 A()가 호출되지 않아서 "생성자 of A"가 출력되지 않았습니다. -> 혹시 어떤 부분이 다르기에 부모의 기본생성자가 호출되지 않은건가요? 감사합니다.
전체적으로 강의도 1회독하고 모의고사나 과거 시험으로 나온 문제도 풀면서 어느정도 언어에 대한 정리는 끝난 상태입니다. 그리고 최근에 만들어주신 각 언어에 대한 기출변형까지 습득을 했다면 언어는 어느정도 마스터했다고 판단하고 제공해주신 이론 PDF로 자주출제되는 쪽부터 암기하면 되겠죠? 작년부터 하고 있어서 마음이 조금 급해지네요ㅠ
안녕하세요. 강의듣고 혼자서 영화 정보 사이트를 만들어보며 공부중에 있습니다. 만들던 중 테이블 설계하는데 궁금증이 생겨 질문드립니다. 해당 사이트는 영화뿐 아니라 드라마 시리즈 정보 또한 제공할 것인데요. 영화, 드라마 시리즈는 둘 다 공통적으로 크레딧(감독 및 출연진 정보)를 가지죠. 처음에는 영화, 시리즈 크레딧 각각의 테이블로 만들려다가 공통되는 부분이 많기에 단일 테이블 전략으로 크레딧을 다음과 같이 만들었습니다. Credit 클래스 { id // pk name // 배우 및 감독 이름 role // 역할 movie series } 이제 질문입니다. 위처럼 단일 테이블 전략으로 만드니 하나의 행에서 영화 또는 series 둘 중 하나는 결국 null 값이어야 할 것입니다. 한 배우의 하나의 영화 또는 드라마 시리즈에 대해서만 나타내는 것이니까요. 그런데 모든 행이 둘 중 하나는 의도적으로 null 값을 가질텐데 null이 있어도 전혀 문제가 없나요? 공부하면서 만든 엔티티들은 아무 생각 없이 하나의 영화는 다수의 크레딧을 가지고, 하나의 시리즈도 다수의 크레딧을 가지니까 연관관계를 맺어야지 하고 만들었습니다. 그런데 생각해보니 굳이 연관관계를 맺지않고, 영화나 시리즈를 나타내는 타입 정보만 넣어서 구분 짓어준다면, 영화의 크레딧인지 시리즈의 크레딧인지 구분하여 조회가 가능하다고 생각합니다. 그래서 이때 연관관계라는 것이 반드시 왜 필요한지 궁금해졌습니다. 이렇게 타입정보로 구분지어 조회가 가능할 때도 연관관계는 반드시 맺어주는게 좋나요?
무료행사(2) 투포인터 문제에서 같은 가격을 가진 상품이 없다고 했으니 while의 else문(target과 일치하는 경우) 에서 l++ 만 하는 것 보다, 어차피 현재의 l, r 값은 검수 완료된거니 l++, r— 둘다 이동하는게 더 적절한 코드 아닌가 생각했는데요. 왜 l++ 만 하신건지 궁금합니다!
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 강의 스크립트 Hibernate5JakartaModule 호출시 에러가 발생하여 확인 차 문의드립니다.ㄴ> om.fasterxml.jackson.datatype.hibernate5.jakarta.Hibernate5JakartaModule Unable to get public no-arg constructor 스프링부트 버전 문제인 것으로 판단하여 프로젝트의 스프링부트 버전확인시 4.1.0 버전으로 실행하였고 해당 버전에서 라이브러리와 클래스 변경이 있는 것 같아 질문 남깁니다. // Hibernate5jakarta // implementation 'com.fasterxml.jackson.datatype:jackson-datatype-hibernate5-jakarta' // -> 변경 // Hibernate7Module implementation 'tools.jackson.datatype:jackson-datatype-hibernate7' package jpabook.jpashop; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.context.annotation.Bean; import tools.jackson.datatype.hibernate7.Hibernate7Module; @SpringBootApplication public class JpashopApplication { public static void main(String[] args) { SpringApplication.run(JpashopApplication.class, args); } // @Bean // Hibernate5JakartaModule hibernate5Module() { // Hibernate5JakartaModule hibernate5JakartaModule = new Hibernate5JakartaModule(); //// // 강제 지연 로딩 설정 // hibernate5JakartaModule.configure(Hibernate5JakartaModule.Feature.FORCE_LAZY_LOADING, true); // return new Hibernate5JakartaModule(); // } // ㄴ 변경 @Bean Hibernate7Module hibernate7Module() { Hibernate7Module hibernate7Module = new Hibernate7Module(); // 강제 지연 로딩 설정 // hibernate7Module.configure(Hibernate7Module.Feature.FORCE_LAZY_LOADING, true); return hibernate7Module; } }
안녕하세요. 백엔드/서버 개발자로 이직을 준비하고 있는 1년차 SI 개발자입니다. 강의를 들으면서 늘 느끼는 점이 있습니다. 강의에서 보여주시는 코드는 정말 간결하고 효율적이고, 특히 “한 사람이 조금 더 고민해서 코드를 작성하면 다음 사람이 유지보수하기 편하다”는 말씀에 많이 공감하고 있습니다. 저도 실무에서 신규 기능을 추가하거나 기존 기능을 수정할 때 다른 사람이 작성한 코드를 보게 되는데, 그때마다 유지보수하기 쉬운 코드의 중요성을 많이 느끼고 있습니다. 그런데 최근 작업을 하면서 한 가지 의문이 생겼습니다. 어떤 코드에서 분기 조건만 다르고, 마지막에 호출하는 메서드 형식은 완전히 같은 상황이 있었습니다. 예를 들면 if문 안에서 조건에 따라 넘겨주는 값만 다르고, 최종적으로 호출하는 메서드는 동일한 구조였습니다. 처음에는 각 분기 안에서 바로 메서드를 호출하면 코드 흐름이 단순해 보였습니다. if (조건1) { Method(a, b, c); } else if (조건2) { Method(d, e, f); } 하지만 이렇게 작성하면 호출 형식이 계속 반복되고, 나중에 파라미터가 추가되거나 호출 방식이 바뀌면 여러 군데를 수정해야 해서 유지보수성이 떨어질 것 같았습니다. 그래서 조건에 따라 필요한 값만 먼저 변수에 세팅하고, 마지막에 메서드는 한 번만 호출하는 방식이 더 낫다고 생각했습니다. if (조건1) { value1 = a; value2 = b; value3 = c; } else if (조건2) { value1 = d; value2 = e; value3 = f; } Method(value1, value2, value3); 이 방식은 호출부 중복은 줄어들지만, 반대로 코드 길이는 늘어나고 중간 변수가 많아집니다. 또 단순한 if문 하나로 처리할 수 있는 로직을 굳이 변수 세팅 방식으로 바꾸는 게 항상 좋은 선택인지 고민이 됩니다. 결국 궁금한 점은 이것입니다. 분기마다 값만 다르고 호출 형식이 같은 경우, 실무에서는 어떤 기준으로 코드를 작성하는 것이 더 좋은가요? 단순히 코드 줄 수가 짧은 것이 좋은 코드인지, 아니면 조금 길어지더라도 중복 호출을 줄이고 변경 지점을 한 곳으로 모으는 것이 좋은지 아직 실무 경험이 부족해서 판단이 어렵습니다. 이런 상황에서 실무적으로 어떤 기준으로 리팩토링 여부를 판단하면 좋을지 궁금합니다.
