코드 몽키의 허둥지둥 개발공부

리마인드용으로 작성함! PK 인덱스와 세컨더리 인덱스의 구조 B-Tree PK 인덱스와 세컨더리 인덱스 모두 루트 노드 > 브랜치 노드 > 리프 노드의 구조를 갖는 것은 동일하다. 또한, PK 인덱스와 세컨더리 인덱스 모두 루트 노드 또는 브랜치 노드는 자식 노드의 주소를 갖는다. 그러나 세컨더리 인덱스는 리프 노드에서 관리되는 인덱스의 값(value)이 프라이머리 키를 가리키는 반면, PK 인덱스에서는 리프 노드에 실제 레코드가 저장된다. 참고. InnoDB 에서의 데이터 파일 기본적으로 MySQL의 스토리지 엔진 중 InnoDB 에서는 PK 인덱스가 데이터 파일의 역할을 수행하며, PK 인덱스 자체가 데이터 파일이다. 이는 MyISAM 엔진에서는 데이터 파일에 실제 레코드가 저장되는 것과 대비된다.

Using where MySQL은 내부적으로 스토리지 엔진과 MySQL 엔진이라는 두 계층으로 나뉘며, 각각 다음과 같은 역할을 수행한다. 스토리지 엔진: 디스크나 메모리 상에 존재하는 레코드 중 필요한 것을 읽거나 저장한다. MySQL 엔진: 스토리지 엔진으로부터 전달 받은 레코드를 가공하거나 연산한다. 이 때, 실행 계획의 Extra 컬럼에 표시된 Using where는 MySQL 엔진 계층에서 별도의 필터링을 처리한 경우를 의미한다. Using index 커버링 인덱스라고도 하며, 실제 데이터 파일을 전혀 읽지 않고도 인덱스만 읽어들여 쿼리를 모두 처리할 수 있는 경우이다. 예를 들어, SELECT 절에서 선택하는 컬럼과 임의의 인덱스에 명시된 컬럼이 같은 경우 실제 데이터 레코드 파일을 읽는 대신..

TL;DR any: 대상에 대한 타입 검사를 포기한다. 즉, TS를 사용하는 이유를 무색하게 만드므로 사용을 지양하는 것이 바람직하다. unknown: 아직은 대상의 타입을 알 수 없으나, 반드시 명시적으로 형변환 또는 타입 가드를 적용하여 안전하게 사용해야 한다. 때문에 반드시 any 대신 unknown을 사용해야 한다! 타입 가드의 경우, 원시 타입이라면 typeof / 인스턴스라면 instanceof / 객체라면 in 연산자 등을 활용할 수 있다. 그 이외의 경우에 사용자 정의 타입 가드를 구현할 수 있다.

Id UserId Name 1 ingnoh NULL 2 injuk NULL ... N someone NULL 요런 테이블을 Id UserId Name 1 ingnoh ingnoh 2 injuk injuk ... N someone someone 요렇게 업데이트 치고 싶으면 UPDATE [테이블_이름] SET Name = UserId Where [테이블_이름].Id>0; 이렇게

AWS lambda 노드 런타임을 사용할 때, 공통 코드를 layer(계층)에 관리하고 있다면 다음과 같이 import하여 사용하게 된다. const myLibrary = require('/opt/myLibrary'); exports.handler = function(event, context) { myLibrary.greeting(); // hello! } 그러나 해당 코드를 로컬에서 테스트하는 경우, 계층에 포함된 라이브러리가 로컬 환경의 /opt 하위 경로에 존재하지 않으므로 모듈을 임포트할 수 없는 문제가 발생한다. jest를 사용하여 테스트하는 경우, jest.config.js에 다음과 같이 작성하여 문제를 쉽게 해결할 수 있다. module.exports = { moduleNameMapper:..

잘 사용하고 있던 H2 데이터베이스 경로 상의 mv.db를 지웠다든지 하는 문제로 해당 메시지가 노출될 수 있다. 요런 문제는 그냥 다음과 같은 순서로 진행하여 해결할 수 있다. 우선 켜져있는 h2를 모두 끈 후에 다시 켠다. jdbc:h2:~/경로/데이터베이스명 형태로 접속을 시도한다. 접속이 잘 되면 연결을 끊고, 다시 jdbc:h2:tcp://localhost/~/경로/데이터베이스명 형태로 접속한다. 예를 들어 ~/worskpace/study 경로에 test.mv.db를 실수로 지운 경우, 2.의 과정에서는 jdbc:/h2:~/workspace/study/test 형태로 접속해야한다.

DTO 계층 간 데이터 교환에 사용한다. 게터와 세터를 제공하므로, 가변적이다. VO 값 객체이며, 불변적이다.

업무 도중에 Node.js로 다음과 같은 기능을 작성할 일이 있었다. 수 많은 Promise를 생성하되, 각각의 Promise는 1:1로 대응되는 stream의 end 또는 error 이벤트에서 상태가 결정된다. Promise.all로 작업이 완료되는 것을 기다린다. 후속 작업을 처리한다. 그런데 await Promise.all(promises); 에서 대기하던 중 Node.js 애플리케이션이 아무런 로그 없이 code 0으로 정상 종료되는 상황이 발생하였다. (물론 코드 전역에 try - catch를 걸어도 어떠한 에러도 잡히지 않았다.) 해당 문제의 원인은 다음과 같으며, 핵심은 stream의 에러 또는 스펙이 아닌 Node.js 동작 방식에 있었다. Node.js는 애플리케이션을 실행할 경우, 이벤..