본문 바로가기

분류 전체보기

(461)
스프링 배치 - DB 스키마 생성 (2) JOB 관련 테이블 batch_job_instance - job이 실행될 때 jobinstance 정보가 저장되며 job_name과 job_key를 키로 하여 하나의 데이터가 저장 - 동일한 job_name과 job_key로 중복 저장될 수 없다. BATCH_JOB_EXECUTION - job의 실행정보가 저장되며 Job 생성, 시작, 종료 시간, 실행 상태, 메세지 등을 관리 BATCH_JOB_EXECUTION_PARAMS - Job과 함께 실행되는 Job parameter 정보를 저장 BATCH_JOB_EXECUTION_CONTEXT - job의 실행동안 여러가지 상태정보, 공유 데이터를 직렬화 9Json 형식) 해서 저장 - step간 서로 공유 가능함 Step 관련 테이블 BATCH_STEP_EX..
스프링 배치 시작 - DB 스키마 생성 및 이해 (1) 1. 기본 이해 1-1. JobExecution 클래스 Job이 실행되는 동안 생성이 된다. job의 실행 정보, 상태 정보를 담고있다. 1-2 StepExecution 클래스 Step도 실행되는 동안 StepExecution이 생성된다. step의 실행 정보, 상태 정보 1-3 실행 정보, 상태 정보 저장 저장되어 있는 table을 스프링 배치에서 기본적으로 제공하고 있다. 스크립트를 가지고 적용할 수 있다. 스크립트를 가지고 테이블을 생성해서 실행정보, 상태정보를 저장하면 된다. 실행정보 상태정보를 메타데이터라고 한다. 2. DB job이 몇시에 실행이 되었으며, 최종 종료된 상태는 어떤 상태인지 실행정보와 상태정보를 database에 저장하는 단계가 있다. 2-1 db 저장의 이점 그래야 우리가 j..
스프링 배치 시작 - 연습용 배치 생성 1. 기본 설정 스프링 배치를 실행하기 위해, 기본적인 설정을 추가해주자. pom.xml org.springframework.boot spring-boot-starter-batch com.h2database h2 runtime org.projectlombok lombok 1.18.24 provided 2. 스프링 배치 실행 스프링 배치의 구조는 아래와 같다. Job은 여러개의 Step을 가질 수 있으며, Step은 여러개의 Tasklet을 가질 수 있다. Tasklet은 Business logic이라고 볼 수 있다. 코드를 작성해보자. package io.springbatch.springbatch; import lombok.RequiredArgsConstructor; import org.springfra..
spring batch - 프로젝트 구성 및 의존성 설정 1. 스프링 배치 활성화 스프링 배치를 실행시키기 위해서는 선언해야 하는 어노테이션이 있다. @EnablebatchProcessing 2. @EnableBatchProcessing 어노테이션이란? 1. 총 4개의 설정 클래스를 실행시킨다. 2. 스프링 배치의 모든 초기화 및 실행 구성이 이루어진다. 3. 스프링 부트 배치의 자동 설정 클래스가 실행됨 - 빈으로 등록된 모든 Job을 검색해서 초기화 - 초기화 됨과 동시에 모든 Job을 수행하도록 구성됨. (수동으로 실행이 되게 할 수도 있다.) 3. 4개의 설정 클래스? 1. BatchAutoConfiguration 2. SimpleBatchConfiguration 3. BatchConfigurerConfiguration - BasicBatchConfig..
df git add 명령어로 staging 한 파일들을 다시 되돌리려면 git reset 을 사용해준다. Git(31) git add 취소하기 (staging 취소) 앗 ! 실수로 git add . 를 하여 변경한 전체 파일을 staging 했다. 😵‍💫 당황치 말고 git reset 으로 다시 unstaged 상태로 되돌리자 🤓 만약, 특정 파일만 unstaged로 되돌리고 싶다면 ? git reset 뒤에 파일경로를 적어주면 해결!
Git의 Staging Area는 어떤 점이 유용한가 Git의 Staging Area는 어떤 점이 유용한가 Git에는 Staging Area라는 공간이 있다. 어떤 변경사항이 저장소에 커밋되기 전에, 반드시 거쳐야만 하는 중간단계이다. 다른 버전관리도구에는 이에 정확히 대응하는 것은 없다. 저장소가 추적하는(관심의 대상이 되는) 파일들의 목록을 유지하고, 그 파일들에 대한 메타데이터를 관리하는 것은 다른 저장소들도 하는 일이지만, Git 처럼 커밋될 예정인 파일의 내용들까지 기억하지는 않는다. 이 Staging Area의 존재는 처음 Git을 사용하는 입장에서는 그저 불편만 안겨주고 이해만 더디게 만들어주는 목적불명의 무언가에 지나지 않는다. 다른 SCM에선 파일을 고치고 바로 커밋하면 되었는데, Git은 반드시 그 전에 add를 해 줘야 한다. 이런 비용..
[Git] Git 3가지 영역 (Staging Area) - Commit 이해하기 Staging Area Commit을 할 때, 총 3가지 영역을 바탕으로 작동합니다. Working Directory : 내가 작업하고 있는 프로젝트의 디렉토리 Staging Area : 커밋을 하기 위해 $ git add 명령어로 추가한 파일들이 모여있는 공간 Repository : 커밋들이 모여있는 저장소 열심히 코드를 작성하다가 커밋을 해야하는 순간이 오면 git add .를 통해 커밋할 파일들을 추가합니다. 이 파일은 바로 Repository에 올라가지 않고, Staging Area에 올라가게 됩니다. Staging Area에 추가한 파일들을 Commit을 한다면 최종적으로 저장소(Repository)로 저장되게 됩니다. File Status LifeCycle File 관점에서는 다시 4가지 단계..
[Git] Git HEAD, reset 옵션 3가지 (hard, mixed, soft) HEAD 란? 현재 내가 위치해있는 커밋을 가리키는 식별자입니다. 보통 커밋을 가리킬 때에는 HEAD가 간접적으로 브랜치를 통해서 가리키게 되는데 아래의 형태가 바로 그 모습입니다. HEAD가 master 브랜치를 통해 간접적으로 세번째 커밋을 가리키고 있습니다. $ git reset --{option} {commit_id} HEAD가 가리키는 커밋에 따라 working directory의 형태도 바뀌게 됩니다. 한번 첫번째 커밋으로 이동해 보겠습니다. (옵션은 아래에서 설명하겠습니다.) $ git reset --hard {commit_id} 첫번째 커밋으로 이동했더니 두번째 커밋과 세번째 커밋이 없어졌습니다. 자 이제 다시 최신 커밋인 세번째 커밋으로 이동합시다. 어라, $ git log로 세번째 커밋..