addressHistory는 조회하기 위한 select 쿼리가 날아가는데, favoriteFood는 select 쿼리가 날아가지 않는 이유가 궁금합니다.

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]여기에 질문 내용을 남겨주세요.   안녕하세요! 컬렉션 페치 조인 용어에서 간단한 질문이 있습니다. 컬렉션 조회 최적화 수업을 듣게 되면, OneToMany 관계에서 컬렉션 페치 조인을 하게 됩니다. 이때, 만약 '컬렉션 페치조인에서 컬렉션이 무엇이고 페치 조인이 무엇이에요?'라는 질문이 들어오면   먼저 findAllWithItem() 메서드를 예시로보면, (1) 페치 조인은     Order 테이블을 기준으로 member, delivery, orderItems, item 이 페치조인이 일어나고,     (2) 컬렉션 orders 변수에 select문 결과를 저장 컬렉션 orders 변수에 select문 결과를 저장한다.   이와 같이 컬렉션와 페치조인이 사용되는 것을 컬렉션 페치조인이라고 한다.   라고 설명을 한다면 괜찮은 답안일까요? (나중에 면접에서 설명하라고 하셨을 때 이와 같이 하면 될지 고민이 많이되네요ㅠㅠ)

안녕하세요. 컬렉션과 스토어 정리가 잘 되지 않아 질문드립니다. https://www.inflearn.com/questions/265095 를 읽고나서 조금 더 혼란스러워서요..ㅠㅠ 위 질문에서 DELETE /members/{memberid} 는 생성/관리의 역할을 서버가 맡고 있다고 보는것이 맞다라고 답변이 적혀있는데요. 강의에서는 PUT /files/{filename} 은 클라이언트가 리소스의 URI를 알고 관리하기 때문에 /files는 스토어라고 설명되고 있습니다. 형태만 봤을 땐 files나 members의 URI 형태나 처리하는 방식이 비슷해 보여서 정리가 되지 않습니다.ㅠPUT /files/{filename} 은 파일 자체를 만들어주는것이(생성)이 아니라서 스토어이고,DELETE /members/{memberid}는 멤버정보를 DB에 저장해서 하나의 회원을 생성/관리(수정,삭제)하기 때문에 컬렉션이라고 이해하면 될지요?그게 아니라면 파일도 결국 members처럼 파일정보를 넘겨서 파일은 서버에 저장하고, 파일정보는 DB에 저장하므로 서버에서 처리하는게 아닌가하는 의문이 듭니다.매번 답변해주셔서 감사합니다 :)

[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예   [질문 내용] https://www.inflearn.com/questions/379070 이전 질문을 통해  t.member as m 임을 이해하였습니다.  하지만 아직 1가지 의문이 듭니다.   질문 1) String query = "select t.members from Team t"; 위 코드는 묵시적 조인이 발생하고, 따라서 t.members.username 과 같은 호출은 불가능하게 됩니다.  왜냐하면 members는 collection이기 때문에 size와 같은 collection에 대한 정보는 얻어올수 있어도, collection 안에 있는 원소에 대한 정보를 얻어올수는 없기 때문이죠.   따라서 강의에서는 다음과 같이 명시적 조인으로 바꾸면 select m.username from Team t join t.members m 과 같이 m.username 와 같은 사용이 가능하다고 하셨습니다.   하지만 두 코드 모두  1. select t.members from Team t 2. select m from Team t join t.members m (member를 가져오기 위해 select m으로 변경) 동일한 SQL 생성됨을 알수있었습니다. 1. select t.members from Team t 2. select m from Team t join t.members m 두 코드 모두 같은 SQL문을 보여주더군요!   여기서 질문!! 둘다 같은 SQL을 생성하는데 SELECT 절에서 왜 묵시적 조인 쪽은 username에 접근이 안되고, 명시적 조인은 username에 접근이 가능한가요?   select t.members from Team t 에 의해서 생성되는 SQL 문을 A select m from Team t join t.members m 에 의해서 생성되는 SQL 문을 B 라고 한다면 A랑 B랑 같은 SQL문을 보여주는데,  B에서 username을 얻어올 수 있듯, A에서 username을 얻어올수 있지 않을까? 생각해서 질문 남겨봅니다.   (참고로 t.members는 collection자체이기 때문에 원소 자체의 필드인 username에 접근 불가능하며 m은 Member 엔티티니까 m.username, m.age와 같이 접근 가능한것은 알겠는데,  이는 JPQL상의 코드에서 나타나는 차이지 SQL상에서는 동일하게 SELECT 쿼리를 보내는것 같아서요.)   저의 질문 의도가 좀 명확하지 않다면 죄송합니다 ㅠ.ㅠ

안녕하세요. 좋은 강의 잘 듣고 있습니다. 강의를 듣다가 궁금한 점이 생겨서 질문 남깁니다. 만약  /members  -> post  // 새로운 멤버 생성 /members/{memberid}  -> delete  // 멤버삭제 이런식으로 api를 설계할 경우에는 members는 post와도 관련이 있고 delete와도 관련이 있게됩니다. 그렇다면 이런 경우에는 /members 는 컬렉션인 동시에 스토어가 되는 건가요?

안녕하세요. 연관관계 주인이 아닌 List로 구현된 members에서 궁금한 점이 있습니다. 먼저 지금까지 이해한 바로는, @Entity 애노테이션과 ddl-auto 속성에 의해서 @Entity를 가진 클래스의 필드들이 해당 테이블의 attribute로 만들어지는 것으로 이해했습니다. 1. @Column이 DB 테이블의 실제 컬럼 이름과 매핑을 짓는 용도라고 이해했는데 @Column을 생략해도 DB상에 해당 컬럼이 생성된 것을 확인했습니다. 이 경우, 컬럼은 생성됐지만 매핑은 이루어지지 않은건가요? 2. Team 클래스의 members 어레이리스트는 Team 테이블의 attribute로 등록되지 않는 이유가 뭔가요? 물론, 데이터베이스 상에서 하나의 attribute에 하나의 값을 가져야 하는건 맞지만 이게 컬렉션으로 구현된 필드는 JPA에서 자동으로 attribute이 아니라고 인식하는 건가요?