💡 질문하기 전에 먼저 확인해보세요! 답변을 기다리는 동안, 아래 항목들을 먼저 확인해보시면 문제가 해결될 수도 있어요. 강의 내용 다시 보기: 혹시 놓친 부분이 없는지 해당 챕터의 강의를 한 번 더 돌려보셨나요? 오타 및 들여쓰기 확인: 파이썬은 특히 들여쓰기에 민감해요. 코드에 오타나 잘못된 들여쓰기는 없는지 꼼꼼히 확인해주세요. 에러 메시지 검색: 빨간색 에러 메시지가 떴다면, 메시지 전체를 복사해서 구글에 그대로 붙여넣기 해보세요. 전 세계 개발자들이 비슷한 문제를 겪고 해결책을 공유해두었을 확률이 높습니다. Q&A 게시판 검색: 혹시 다른 분이 먼저 비슷한 질문을 올렸는지 게시판을 한번 살펴보는 것도 좋은 방법이에요. 해당 강의 화면에서 코드를 보고 설명하시는 것 같은데 화면이 계속 인프런 강의소개 페이지인데 제가 맞게 보고 있는걸까요?
안녕하세요. Airflow 3.0 에서 EmailOperator 사용시 conn_id 를 세팅하지 않으면 smtp_default 를 기본적으로 사용하고 있어보입니다. smtp_default 세팅은 config 파일에 보니 email_conn_id(AIRFLOW__EMAIL__EMAIL__CONN__ID) 에 세팅되어 있어 EmailOperator 와 fail났을때 smtp_default를 세팅해놓으면 동시에 사용 가능한것은 아닐까요?
선생님 안녕하세요. 최대 혹은 최소값으로 ans를 int(1e6, 1e7, 1e8) 등 다양하게 설정하시는데 혹시 기준이 있을까요? 문제를 풀다 보면 탐색 전에 미리 최소값이나 최대값을 세팅해야 하는 경우가 있는데, 그 세팅의 베스트 프랙티스나 혹은 float(int) 같이 최대/최소값을 따로 정하시는 로직이 후반부에 나오는지 궁금합니다.
POST API 첫번째 강의에서 main.py의 52번 줄에 request를 dict() 형식으로 꼭 맞춰 주어야하나요?? 출력은 request >> id=4 contents='aaa' is_done=True request.dict() >> {'id': 4, 'contents': 'aaaa', 'is_done': True} 이렇게 되는데, 그냥 request 만 써도 swagger UI에서 보았을 땐 똑같이 dict 형식으로 들어오더라구요. 궁금해서 문의드립니다.
안녕하세요. 김판다 강사님을 보조하는 이조교 입니다. 저는 강사님 개인 메일로 도착한 질문들을 정리해, 다른 수강생분들께도 도움이 되도록 질문 게시판에 깔끔하게 편집해 올리고 있습니다. 개인 메일( pandakimt@gmail.com )로 질문하셔도, 강사님이 활발히 답변해드립니다. 제목: 구글 코랩에서는 셀마다 변수 값을 다시 정의해야 하나요? 구글 코랩에서는 셀마다 변수 값을 다시 정의해야 하나요? 아니면 첫 번째 셀에서 x = 10 이라고 하면, 두 번째 셀에서도 x 를 그대로 쓸 수 있나요?
[리뉴얼] 처음하는 파이썬 데이터 분석 (쉽게! 전처리, pandas, 시각화 전과정 익히기) [데이터분석/과학 Part1]
현재 강의 수강 중에 참고 엑셀 파일들을 활용하여 실습을 진행할려고하는데 강의 7에서 다운 받은 자료에서 COVID-19-master 관련 등 자료들이 누락된거 같아서 혹시 별도 첨부파일이 있는지 아니면 강의 28부터 실습에 사용하는 참고 자료들을 별도로 받을 수 있을까요 ?
안녕 킬구횽. 정성 가득한 강의 감사한 마음으로 공부하고 있다. 고맙다. 다름이 아니라, 해당 작전에서 설명한대로 TransactionManager을 분리해서 사용하고 있었는데, 이때 이해가 가지 않는 상황이 있다. 글이 조금 길어서, 요약을 먼저 하겠다. 요약 비즈니스용 트랜잭션 매니저(JPA) 과 메타데이터용 트랜잭션 매니저(JDBC) 을 분리한 경우 , UnexpectedRollbackException 이 발생한 후에 OptimisticLockingFailureException 까지 추가로 발생한다. 그러나 트랜잭션 매니저를 분리하지 않은 경우 , UnexpectedRollbackException 은 발생하지만 OptimisticLocking 예외는 발생하지 않는다 . 이유가 궁금하다. 상황 설명 다음은 @Configuration 클래스다. @Bean @Primary @ConfigurationProperties("spring.datasource.service") public DataSource dataSource() { return DataSourceBuilder.create() .type(HikariDataSource.class) .build(); } @Bean @BatchDataSource @ConfigurationProperties("spring.datasource.batch") public DataSource batchDataSource() { return DataSourceBuilder.create() .type(HikariDataSource.class) .build(); } @Bean @Primary public PlatformTransactionManager transactionManager(EntityManagerFactory entityManagerFactory) { return new JpaTransactionManager(entityManagerFactory); } @Bean @BatchTransactionManager public PlatformTransactionManager batchTransactionManager(@BatchDataSource DataSource dataSource) { return new JdbcTransactionManager(dataSource); } 다음은 job을 구성하는 ( 잘못 작성된 ) tasklet이다. 트랜잭션 전파 속성은 Propagation.REQUIRED를 사용하고 있다. class TestTasklet implements Tasklet{ private final TestRepository testRepository; @Override public RepeatStatus execute(StepContribution contribution, ChunkContext chunkContext) throws Exception { try{ // testRepository의 @Transactional method 호출 // but @Transactional method에서 RuntimeException을 throw } catch(RuntimeException e){ // sucess process logic } return RepeatStatus.FINISHED; } 위 코드에서, 예외를 캐치하는 것으로 예외를 처리한 것은 나의 실수였다. 런타임 예외를 던지는 트랜잭션은 rollback-only 마킹 처리되어 해당 트랜잭션이 커밋될 수 없었기 때문이다. 이해가 가지 않는 지점은 지금부터다. 이를 설명하기 위해 내가 파악한 흐름을 정리해봤다. 오류가 있을 수 있다. (비즈니스: JPA / 메타 데이터: JDBC) 트랜잭션 매니저를 분리하는 경우 TransactionTemplate의 execute 메서드 실행 doInTransaction 메서드 실행 시작 TestTasklet의 execute 메서드의 실행 * transaction from JPA execute 메서드 내부에서 런타임 예외가 발생하는 트랜잭션 메서드 호출 -> 트랜잭션에 rollback-only 마킹됨 내부적으로 정상 처리하였으므로 RepeatStatus.FINISHED 반환 StepExecution update (version 1 -> version 2) 커밋 * 메타데이터용 DB 커넥션 사용하는 것을 확인함 doInTransaction 메서드 실행 완료 TransactionTemplate의 execute 메서드에서 커밋 시도 * transaction from JPA UnexpectedRollbackException 발생 * rollback-only 마킹으로 인함 롤백 시작 version 1 -> version 2로 StepExecution update 시도 이때 다음 예외가 발생한다. OptimisticLockingFailureException: Attempt to update step execution id=4 with wrong version (1), where current version is 2 반면, 트랜잭션 매니저를 분리하지 않으면 OptimisticLocking 예외가 발생하지 않는데, 왜 OptimisticLocking 예외가 발생하지 않는지 궁금하다. (비즈니스, 메타 데이터: JPA ) 트랜잭션 매니저를 분리하지 않는 경우 TransactionTemplate의 execute 메서드 실행 doInTransaction 메서드 실행 시작 TestTasklet의 execute 메서드의 실행 execute 메서드 내부에서 런타임 예외가 발생하는 트랜잭션 메서드 호출 -> 트랜잭션에 rollback-only 마킹됨 내부적으로 정상 처리하였으므로 RepeatStatus.FINISHED 반환 StepExecution update (version 1 -> version 2) 커밋 doInTransaction 메서드 실행 완료 TransactionTemplate의 execute 메서드에서 커밋 시도 UnexpectedRollbackException 발생 롤백 시작 version 1 -> version 2로 StepExecution update 시도 OptimisticLock 예외가 터지지 않고 정상적으로 버전 업데이트가 완료된다. 이때 OptimisticLocking 예외가 발생하지 않았다는 것은, 현재 stepExecution의 버전이 1 이라는 것으로 받아들여진다. 의문인 점은, StepExecution update (version 1 -> version 2)이 커밋되는 것을 디버깅을 통해 확인했는데, 어째서 롤백 시점에서 stepExecution의 버전이 1이냐는 것이다. 무언가 엔티티 매니저와 관련이 있는 것 같은데, 잘모르겠다. 도움이 될까하여, 로그 일부를 첨부한다. 트랜잭션 매니저 분리하는 경우 2025-07-27T22:16:13.626+09:00 TRACE 141032 --- [server] [ main] o.s.jdbc.core.StatementCreatorUtils : Setting SQL statement parameter value: column index 1, parameter value [28], value class [java.lang.Long], SQL type unknown 2025-07-27T22:16:13.626+09:00 TRACE 141032 --- [server] [ main] o.s.t.i.TransactionInterceptor : Completing transaction for [org.springframework.batch.core.repository.support.SimpleJobRepository.update] 2025-07-27T22:16:13.626+09:00 DEBUG 141032 --- [server] [ main] o.s.jdbc.support.JdbcTransactionManager : Initiating transaction commit 2025-07-27T22:16:13.626+09:00 DEBUG 141032 --- [server] [ main] o.s.jdbc.support.JdbcTransactionManager : Committing JDBC transaction on Connection [HikariProxyConnection@33286612 wrapping org.postgresql.jdbc.PgConnection@6ae1d5f1] 2025-07-27T22:16:13.627+09:00 DEBUG 141032 --- [server] [ main] o.s.jdbc.support.JdbcTransactionManager : Releasing JDBC Connection [HikariProxyConnection@33286612 wrapping org.postgresql.jdbc.PgConnection@6ae1d5f1] after transaction 2025-07-27T22:16:13.627+09:00 DEBUG 141032 --- [server] [ main] o.s.jdbc.support.JdbcTransactionManager : Resuming suspended transaction after completion of inner transaction 2025-07-27T22:16:13.627+09:00 DEBUG 141032 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Initiating transaction commit 2025-07-27T22:16:13.627+09:00 DEBUG 141032 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Committing JPA transaction on EntityManager [SessionImpl(858762286<open>)] 2025-07-27T22:16:13.630+09:00 INFO 141032 --- [server] [ main] o.s.batch.core.step.tasklet.TaskletStep : Commit failed while step execution data was already updated. Reverting to old version. 2025-07-27T22:16:13.630+09:00 DEBUG 141032 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Closing JPA EntityManager [SessionImpl(858762286<open>)] after transaction 2025-07-27T22:16:13.630+09:00 DEBUG 141032 --- [server] [ main] o.s.batch.repeat.support.RepeatTemplate : Handling exception: org.springframework.transaction.UnexpectedRollbackException, caused by: org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only 2025-07-27T22:16:13.631+09:00 DEBUG 141032 --- [server] [ main] o.s.batch.repeat.support.RepeatTemplate : Handling fatal exception explicitly (rethrowing first of 1): org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only 2025-07-27T22:16:13.633+09:00 ERROR 141032 --- [server] [ main] o.s.batch.core.step.AbstractStep : Encountered an error executing step switchAliasTargetStep in job addressIndexingJob 분리하지 않는 경우 2025-07-27T22:18:22.239+09:00 TRACE 114800 --- [server] [ main] o.s.jdbc.core.StatementCreatorUtils : Setting SQL statement parameter value: column index 1, parameter value [8], value class [java.lang.Long], SQL type unknown 2025-07-27T22:18:22.240+09:00 TRACE 114800 --- [server] [ main] o.s.t.i.TransactionInterceptor : Completing transaction for [org.springframework.batch.core.repository.support.SimpleJobRepository.update] 2025-07-27T22:18:22.240+09:00 DEBUG 114800 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Initiating transaction commit 2025-07-27T22:18:22.240+09:00 DEBUG 114800 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Committing JPA transaction on EntityManager [SessionImpl(707576293<open>)] 2025-07-27T22:18:22.241+09:00 INFO 114800 --- [server] [ main] o.s.batch.core.step.tasklet.TaskletStep : Commit failed while step execution data was already updated. Reverting to old version. 2025-07-27T22:18:22.242+09:00 DEBUG 114800 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Closing JPA EntityManager [SessionImpl(707576293<open>)] after transaction 2025-07-27T22:18:22.242+09:00 DEBUG 114800 --- [server] [ main] o.s.batch.repeat.support.RepeatTemplate : Handling exception: org.springframework.transaction.UnexpectedRollbackException, caused by: org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only 2025-07-27T22:18:22.242+09:00 DEBUG 114800 --- [server] [ main] o.s.batch.repeat.support.RepeatTemplate : Handling fatal exception explicitly (rethrowing first of 1): org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only 2025-07-27T22:18:22.246+09:00 ERROR 114800 --- [server] [ main] o.s.batch.core.step.AbstractStep : Encountered an error executing step switchAliasTargetStep in job addressIndexingJob
13. jpa reader,writer 까지만 보고 질문드립니다. JpaPagingItemReader , JpaItemWriter 를 사용해서 JPA 기반으로 DB에 직접 접근해 처리할때, Writer나 Processor에서 복잡한 비즈니스 로직이 필요한 경우 에는 어떻게 설계하는 것이 좋은지 궁금합니다. 만약 주문을 처리하는 배치가 있다고 했을 때 배치 작업에서 주문을 조회 ( JpaPagingItemReader -Entity 리턴) writer에서 주문 상태 변경 주문 내역 추가 배송 테이블에 적재 등 여러 도메인을 걸치는 비즈니스 로직 수행 필요 이렇게 되면 reader에서 조회한 것을 processor에서 command와 같은 객체로 변환해서 writer에서는 service 로직을 호출하는 것이 좋을까요?
클래스의 생성자 강의 내용 중에서, 1. 젤리 리스트 형식에서 jelly=[teddy_jelly('red', 'strawberry'), teddy_jelly('yellow','lemon')]의 teddy_jelly('red', 'strawberry') 이 부분은 함수의 인수로 이해하면 될까요. 그것을 젤리라는 변수에 담은 것으로요. 2. 그리고 jelly인스턴스 속성에 접근하는 방법에서 print(jelly[0].color)는 위의 리스트에서 0번째 위치의 color값을 의미할텐데 .color의 형식이 함수의 표기와 비슷합니다. 이 부분이 맨 위 매소드 작성 시 self.color=color라고 작성한 부분과 관련이 있는지, 아니면 그냥 단순 작성 규칙인 지 질문드립니다.
