qwef

사실 데이터소스에 대해 별도의 설정을 주지 않으면 스프링부트는 자동으로 임베디드 DB를 만들어 준다. @Import(JdbcTemplateV3Config.class) @SpringBootApplication(scanBasePackages = "hello.itemservice.web") public class ItemServiceApplication { public static void main(String[] args) { SpringApplication.run(ItemServiceApplication.class, args); } @Bean @Profile("local") public TestDataInit testDataInit(ItemRepository itemRepository) { return n..

H2 DB는 자바로 개발되어 있다. JVM안에서 메모리 모드로 동작하는 특별한 기능을 제공한다. 즉, 휘발성인 모드 이다. DB를 애플리케이션에 내장해서 함께 실행한다고 해서 임베디드 모드라고 한다. 애플리케이션이 종료되면 임베디드 모드로 동작한 H2 DB도 함께 종료되고 데이터도 모두 휘발된다. 하는 방법이 어렵지는 않다. @Import(JdbcTemplateV3Config.class) @SpringBootApplication(scanBasePackages = "hello.itemservice.web") public class ItemServiceApplication { public static void main(String[] args) { SpringApplication.run(ItemService..

@Transactional @SpringBootTest class ItemRepositoryTest { @Autowired ItemRepository itemRepository; @AfterEach void afterEach() { //MemoryItemRepository 의 경우 제한적으로 사용 if (itemRepository instanceof MemoryItemRepository) { ((MemoryItemRepository) itemRepository).clearStore(); } } @Test void save() { //given Item item = new Item("itemA", 10000, 10); //when Item savedItem = itemRepository.save(item)..

테스트용 DB에서 각 테스트를 끝마치고 난 뒤 원래 상태로 되돌릴 좋은 방법은 바로 롤백이다. 오토커밋 모드를 꺼두면 커밋을 하기 전 까지 내 세션에만 반영이 되어 있기 때문에, 궁극적으로는 DB에 반영이 되지 않는 것이다. 그 상태로 테스트를 하다가, 테스트가 끝난 후, Rollback 시켜버리면 된다. @BeforeEach에 오토커밋 모드를 끈 후, 테스트를 마치고 나면 @AfterEach에서 롤백을 하고 오토커밋 모드를 켜서 원래 상태로 되돌려 놓는다. @SpringBootTest class ItemRepositoryTest { @Autowired ItemRepository itemRepository; @Autowired PlatformTransactionManager transactionManag..

이제 아예 테스트용 DB를 따로 만들었음. jdbc:h2:tcp://localhost/./testcase 이걸로 만듦. 이제 테스트용 DB는 여기다가 쓸 거니 test의 application.properties에 명시해 줌. spring.profiles.active=test spring.datasource.url=jdbc:h2:tcp://localhost/./testcase spring.datasource.username=sa spring.datasource.password=1234 이제 앞으로 test 하위의 코드로 테스트 하면 dataSource를 저기서 가져오기 때문에, 저기 DB를 참조할거임. 격리는 했다. 이제는 테스트 후 DB를 원래상태로 되돌려 놓게끔 해야 한다. 테스트는 다른 테스트와 격리..

이제 DB 기술을 직접 서비스 하기 전에 CRUD 등 테스트 해보는 게 필요하니, 테스트 할 때마다 직접 서버를 띄워서 하기보다는, 따로 테스트를 편리하게 만드는 게 좋음. 테스트에 @SpringBootTest 이 애노테이션이 붙어 있으면, 상위의 @Import(JdbcTemplateV3Config.class) @SpringBootApplication(scanBasePackages = "hello.itemservice.web") public class ItemServiceApplication { public static void main(String[] args) { SpringApplication.run(ItemServiceApplication.class, args); } @Bean @Profile("..

먼저 SimpleJdbcInsert 말 그대로 insert에 관한건데, insert를 진짜 간단하게 하게끔 도와주는 것이다. @Slf4j @Repository public class JdbcTemplateItemRepositoryV3 implements ItemRepository { private final NamedParameterJdbcTemplate template; private final SimpleJdbcInsert jdbcInsert; public JdbcTemplateItemRepositoryV3(DataSource dataSource) { this.template = new NamedParameterJdbcTemplate(dataSource); //커넥션을 얻어오고 그래야 되기 때문에 필..

우리가 주로 쓰는 이름지정 파라미터의 종류는 Map, MapSqlParameterSource BeanPropertySqlParameterSource 이렇게 있음 Sql 붙은 건 당빠 SqlParameterSource 상속받은거 Map은 그냥 쓰면 되고 MapSqlParameterSource는 그냥 Map처럼 쓰면 되는데, addValue해서 직접 key, value로 추가하고, 근데 이건 Sql에 좀더 특화된 기능을 가지고 있는 Map이라고 함. BeanPropertySqlParameterSource는 자바 빈 프로퍼티 규약을 통해 자동으로 파라미터 객체를 생성한다고 함. 예를 들어 getItemName -> itemName 저 itemName이 key가 되고 getItemName()해서 얻은 게 val..

우리가 sql 할 때 String sql = "update item set item_name = ?, price = ?, quantity = ? where id = ?"; 이렇게 하는데 나중에 뭐 db에 colum이 추가된다던지 하면 저기에다 추가로 넣어야 된다. 근데 그러 한 과정에서 예를들면 저 위에 price랑 quantity 순서가 바뀌거나 등.. 그럼 진짜 큰일난다. 이런 일 없을 거 같지만, 실무에서 막 파라미터 10~20개가 넘어가는 일도 많이 있덴다. 버그 중 가장 고치기 힘든 버그가 DB버그라고 한다. 코드만 고치는 수준이 아니라, DB를 복구해야 하기 때문이다. DB복구하고 데이터 보정하고 넣고.. 들어가야 하는 인적 자원이 어마어마 하다. 코드를 줄이는 것도 중요하지만, 모호함을 제거..

전체적인 그림은 이런 것 같다. 컨트롤러는 여러 개 들어올 수 있고, 서비스는 정말 왠만해서는 하나만 목석같아야 하고, 리포지토리는 DB가 바뀌거나 등 필요에 따라 바뀔 수도 있는데, 리포지토리는 보통 DB에 맞게 구현이 되어 있고 그 중 쓸 거 하나만 선택해서 하는..? 아니 근데 또 필요 저장소가 여러개면 여러 리포지토리 쓸 수 있을 듯? item리포지토리, member리포지토리... 여튼 여러 컨트롤러에, 하나의 목석같은 서비스, 리포지토리는 갈아끼울 수 있다.. 그리고 전체적인 흐름도는