묻고 답해요
141만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
해결됨자바 ORM 표준 JPA 프로그래밍 - 기본편
SEQUENCE 전략 초기값과 호출 횟수 문의드립니다.
안녕하세요. 강의 열심히 듣고 있는 주니어 개발자입니다.강의 내용 똑같이 수행했으나 시퀀스 값이 다른 점이 있어 문의드립니다.(33:05) 부분에서 시퀀스 전략 속성값 initialValue=1, allocationSize=50 으로 설정했을시 persist 이전에 초기값이 -49라고 나오지만 제 환경에서는 초기값이 1로 나옵니다. H2 DB 2.1.214, Hibernate 5.6.10을 사용중인데 혹시 버전이 달라서 그런걸까요?로그에는 시퀀스에 대한 call next value를 호출하지 않으며 제 생각에도 initialValue=1로 명시되어 있기 때문에 초기값이 1인게 정상인 것 같은데 제가 놓치는 부분이 있는지 문의드립니다. 위 질문의 연장선으로 persist 1번 수행시 call next value 수행 결과는 아래와 같은데요. DB 시퀀스 자체의 increment값이 50이어서 51이 되는것은 이해하였습니다. JPA에서 51번째 데이터까지는 DB 시퀀스를 참조하지 않고 메모리에서 꺼내와야하는데 persist로 객체를 2번 저장시 아래와 같이 call next value가 2번 호출이 되고 시퀀스 값은 101이 됩니다.(33:43) 여기서 2번 호출 되는 이유가 JPA 애플리케이션에서 사용하는 allocationSize가 50이기 때문에 추후 자신이 사용할 메모리 시퀀스값을 선점하기 위해서라고 이해했는데요. (DB에는 51로 증가시켜놓고, 2부터 51까지 사용하기 위함) 이렇게 되면 제 경우에는 2를 사용하기 위해서 시퀀스 값을 101로 올려놓는 이상한 동작을 하는 것인데 이해가 가지 않습니다. 또한 위와 같이 52번째 객체 저장시 call next value가 한번 더 수행되어 시퀀스 값은 151이 됩니다.의도한대로 작동은 하지만 시퀀스가 한단계씩 밀려서 작동한다는 것이 이해가 가지 않습니다.
-
미해결자바 ORM 표준 JPA 프로그래밍 - 기본편
현업에서 User의 키값을 고객에게 넘길때...
안녕하세요, 영한님, 서포터즈 님들! 요새 API 스펙에 대해 고민을 많이 하고 있는데요! 예를들어 email을 ID로 로그인하는 User 도메인(엔티티)이 있다고 가정할게요! 실제 db상의 key는 다른 값을 가지고 있습니다! (auto_increment) 유저 목록을 반환할때 유저의 식별자로 db의 키값을, 아니면 email 을 반환하는게 좋을까요?? db의 키값 (auto_increment)를 클라이언트가 알아도 괜찮은건가 싶어서 문의드려요! (이경우 db의 key 내부구현이 드러나는게 아닌가 합니다... )
-
해결됨자바 ORM 표준 JPA 프로그래밍 - 기본편
JPA PK String 관련 문의드립니다
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 아니오 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 안녕하세요 김영한 강사님의 강의를 듣고 프로젝트에 JPA를 적용해보려고 합니다. 기본키의 값을 Long(정수)타입이 아니라 String 타입으로 받고싶은데 JPA에서 따로 지원하는 기능이 있는 지 문의드립니다. ex) YYYYMMDD + 시퀀스값(숫자) 좋은 강의 해주셔서 항상 감사드립니다.
-
미해결실전! 스프링 데이터 JPA
데이터베이스 설계 시에서 일반적인 상황에 대해 여쭤보고싶습니다!
안녕하세요 강사님! 강사님의 강의 영상을 보고 Spring Data JPA 를 학습했던 학생입니다. 다름이 아니라 데이터베이스 설계 시에 다음과 같은 상황에서는 어떤 방법이 일반적인지 실무의 관점에서 조언을 얻고자 합니다. `USER`, `COURSE`, `ASSIGNMENT`, `ASSIGNMENT_SUBMIT` 이렇게 4개의 테이블이 있다고 가정할 때, USER : 사용자 테이블 COURSE : 강의 테이블 ASSIGNMENT : 과제 테이블 ASSIGNMENT_SUBMIT : 학생이 제출한 과제 테이블 ASSIGNMENT_SUBMIT 테이블의 PK가 어떤 형태로 되어야 하는지 각각의 장단점에 대해 생각을 해보았습니다. 1. id 라는 칼럼을 만들어서 Auto_Increment 로 pk 를 관리한다. - 장점 - findById 에서 숫자 인덱스를 이용한 조회를 하기 때문에 조회 속도가 빠르다. - 단점 - 칼럼 하나가 늘어난다. 2. user_id 와 assignment_id 라는 두 개의 칼럼을 이용해서 pk로 관리한다. - 장점 - id 칼럼이 사라진다. - 단점 - jpa 에서 제공하는 기본 findById 가 사라진다. - fk 를 결합하여 pk 를 만드는 레퍼런스를 찾지 못했다.. 정도 있습니다. 만약 강사님이시라면 어떤 선택을 하실지 또한 각각 어떤 장단점이 더 있을지 알려주실 수 있으실까요?
-
미해결작정하고 장고! Django로 Pinterest 따라만들기 : 바닥부터 배포까지
데코레이터 관련(새로운 프로젝트에 적용)
안녕하세요. 강의듣고 난후 새로운 개인적 프로젝트 개발중입니다.(코린이 수준, 비전문 개발자라고 할까요. 코딩은 이번이 거의 처음입니다.) 강의는 accountsapp의 User를 기존 class를 이용하여(class AccountCreateView(CreateView):) 생성하였는데 저는 모델을 적용 class Prouser(models.Model) 하여 생성했습니다. (이메일 인증과정을 추가하느라...) 그리고 프로필 모델을 이렇게 만들었습니다. 그리고 데코레이터 는 강의중에 나오는 데로,,,아래처럼 했더니,,,작동이 잘안됩니다. 유저는 pk가 3인 vend01이라는 로그인 id소유자입니다. 물론 아직 프로필을 생성하지 않은 상태이구요,,, 그런데.... 다른 사람( pk=2)의 프로필 업데이트 페이지로 진입됩니다. 게다가... 만들지 않은 프로필의 주소로 진입시도하면.....아래처럼 나옵니다. 아무리 수정할 려고 여러 코드로 해보아도 해결이 되지 않습니다. 처음 만들어보는 프로젝트라 해결할 부분을 선생님 강의를 들으면서 잘 찾아가고 있는데 여기가 통 해결이 되질 않습니다. 무엇이 문제일런지요???? 그리고 추가로 pk관련 아래 이미지도 맞게 제가 정리한 것인지 검토부탁드립니다. ============================================================================================= 추신)))) 그리고 이 데코레이터 부분을 제대로 작성하고 나면 하나 해결해야 할 부분이 있을 것으로 생각되는데요... 가입유저에 level를 적용하여 customer와 vendor로 나누었습니다. 선생님 강의중에 한명이 두개이상의 프로필을 만들 수 있다고 하셔서, 여기저기 뒤져가며 코딩을 해봤는데 구현이 되질 않았습니다. 그래서 프로필 모델은 하나로 통째로 만들고 유저의 level에 따라 데코레이터를 적용하는 방식으로 해결하려고 구도를 잡았습니다. 그것을 구현하는 과정에 난항이 예상되고 있습니다. 실험삼아 만들어보는 다른 프로젝트에서 모델 하나의 유저에 level를 만들어서 데코레이터 방식은 적용을 해봤는데 잘되었습니다. 그러나 이번 만들어보는 프로젝트에서도 약간의 app들의 구조가 달라 잘 구현될 지 해봐야 알것같습니다. 안되면 그때 또 질문을 남기겠습니다.
-
미해결데이터베이스 중급(Modeling)
강사님. PK를 상속하는 구조가 많이 사용되어 지는지 여쭤보고 싶습니다.
안녕하세요. 이교준 강사님 우선 데이터베이스 설계 부분에 관심이 생겨 강의를 찾아보다 우연히 강의를 수강하게 되었는데 강의 퀄리티가 좋아서 기분이 좋습니다. 감사합니다! 데이터베이스 설계를 학습하기 전에도 간단한 구조는 나름데이터베이스를 공부하면서 익힌 원리를 적용해서 작성을 하고는 했었는데 저의 경우 일반적으로 Id라는 컬럼을 생성해서 PK를 주고 시작하는 형태로 설계를 해왔습니다. 그리고 일대다 컬럼을 찾아 관계를 매핑시킬 떄도 생각없이Id를 외래키로 가져오는 형식을 사용했습니다. 제가 궁금한점은 Id를 외래키로써 가져오면서 동시에 PK로 사용하는 구조 (말씀하시길 PK 상속구조)를 많이 사용하는지 여쭤보고 싶습니다. 예를들어 연습문제와 비슷한 회사 부서 팀이 있다면 이러한 구조에서도 아래와 같이 사용하는게 유용할지 여쭤보고 싶습니다.회사 테이블의 경우 회사Id (PK)부서 테이블의 경우 회사Id(FK/PK), 부서Id (PK)팀 테이블의 경우 회사Id(FK/PK), 부서Id(FK/PK), 팀Id(PK) 제가 언제나 조금 불편하게 생각했던 부분이 1 : M 독립형 구조로 가게되면 예를들어 학생의 경우 학생은 반 테이블과 조인해서 반정보를 가져오고 또 반 테이블과 조인한 정보를 토대로 학년을 조인해서 학년 정보를 가져오는 부분인데 - (1학년 1반 누구누구) 강사님이 사용하신 PK 상속 구조를 사용하게되면 학생에서 그냥 반 테이블과 학년 테이블에 각각 조인시켜주면 되는 구조라서 되게 효율적으로 보여서 질문드립니다