체인의정석

블록체인에서 숫자 데이터의 경우 자리수가 크기 때문에 문자로 처리되는 경향이 있다. 따라서 해당 문자를 숫자로 다시 바꿔주기 위하여 Bignumber 또는 BigInt를 사용해주어야 한다. https://stackoverflow.com/questions/65205604/when-should-i-use-the-bignumber-library When should I use the bignumber library? I am trying to understand when to use the bignumber library. Question 1). As we know, JavaScript has an upper limitation on the Number type which is 2^53, but it also..

개발을 할때 그동안은 로그를 console.log 로 찍어왔다. 이렇게 찍은 console.log 는 그동안 깃에 올리기전에 삭제를 하고 올렸다. 하지만 logger를 사용하면 에러가 날 경우와 로그만 남길 경우 등 분류하여 원하는 상황별로 로그를 뽑아낼 수 있다고 한다. 따라서 에러가 나는 경우 상황별로 로거를 남겨두는 작업을 하면 더 좋다. 적용 방법은 다음과 같았다. 1. 로거 install 2. 로거 세팅 파일 생성 3. 상황별로 맞는 로거 보여주기 회사 내부적으로 쓰는 모듈을 적용한것이지만 상용화된 모듈도 있을것 같다.

근 몇일간 api를 리팩토링 하면서 추가 요청이 있어 동기/비동기 처리를 해주어야 하는 상황이 나오게 되었다. 자바스크립트에서는 블록체인 데이터를 주고 받는 과정에서 많은 시간 고생을 하여 익숙해졌다고 생각했으나, 타입스크립트에서 새로 사용하니 막히는 내용이 많아 정리를 하려고 한다. 우선 응답 객체값에 대한 정의가 이루어져야 하는데 이 부분을 빼먹어서 작동이 안되는 경향이 있었다. 이부분은 다음과 같이 결과 값을 지정해주는 클래스에 Promise를 명시해주는 것을 빼먹어서 작동이 안되었던 것이였다. 아래와 같이 Promise를 해주어야 비동기 처리가 가능해지게 된다. makingResponseItemsArr = async ( transactions, ): Promise => { const promise..

type ORM 공식 페이지에서 날짜를 beteween으로 검색하는 부분이 없어서 찾아보았다. https://github.com/typeorm/typeorm/issues/1221 WHERE, Date, and BETWEEN · Issue #1221 · typeorm/typeorm It appears that there is a bug with how QueryBuilder is handling dates. I only tested with SQLite, but it is possible that this is happening with other implementations. const start = new Date(date)... github.com 위의 검색 결과에서 해답을 찾을 수 있었다. .whe..

calss validator가 여태까지 제대로 작동하고 있지 않음을 체크하였다. 그 이유는 @로 프로퍼티를 설정하고 나서 그 이후에 따로 객체를 만들어서 처리하는 부분을 안 써두었기 때문이다. 따라서 다음과 같은 로직을 추가하였다. export class AddressesController { constructor(private readonly addressesService: AddressesService) {} @Get('contracts/:ethAddress') async findOne( @Param('ethAddress') ethAddress: string, ): Promise { const getContractRequest = new GetContractRequest(ethAddress); con..

다음과 같이 queryBuilder를 사용하면 find() 를 사용할 때보다 더 자유로운 검색이 가능하다. 먼저 getRepository 에는 테이블 이름이 들어가게 되는데 이 테이블은 entites 폴더 안의 dto에 정의를 해둔다. 해당 dto는 데이터베이스와 완전히 똑같은 구조로 정의를 해준다. 이때 계속해서 에러가 나는 부분이 바로 이 entity에 없는 값이라고 에러가 도출되는 부분이였다. 계속해서 해메다가 공식문서를 다시 찾아보게 되었고. https://typeorm.io/#/select-query-builder/ TypeORM - Amazing ORM for TypeScript and JavaScript (ES7, ES6, ES5). Supports MySQL, PostgreSQL, Mari..

검색할때 결과값으로 오는 데이터의 양이 많을 시에는 페이징 처리를 통해서 나누어서 불러 올 수 있다. 페이징 처리는 쿼리문에서 select * from Chain LIMIT 10 OFFSET 1 이런식으로 마지막에 limit에는 한번에 가져올 데이터의 양 offset은 어디서부터 가져오지? 하는 기준점을 잡아주게 된다. 이때 limit에 들어오는 값과 OFFSET에 들어오는 값을 넣어주어야 한다. limit에 들어오는 값은 보통 요청 파라미터에서 rpp로 두고 OFFSET 부분은 page로 둔다. 따라서 설계서에서도 request 부분에 모두 rpp와 page를 두기로 하였다. 또한 만약 페이징 처리가 없는 부분이 있다면 이 부분은 0으로 하여 페이징 처리가 있는 경우의 쿼리문과 페이징 처리가 없는 부분..

이번에는 controller 부분과 dto 부분을 수정하여 구조를 더 체계적으로 만들었다. 주위 선임개발자 분들의 코드를 보고 질문을 하여 받은 피드백을 바탕으로 코드를 체계화 시켜 보았다. 수정전 코드 다음과 같이 이더리움 주소값을 계산하는 조건식을 넣었다. 하지만 이러한 값은 @Param에 객체 클래스를 만들어서 class-validator에 적용시키는것이 더 일반적이다. 참고로 이더리움 주소값은 1. 0x 포함 길이 42 2. 들어오는값은 16진수 이 2가지 조건이고 web3에서의 주소값 검사는 체크썸 검사가 나온 결과갑이라고 볼 수 있다. async findOne( @Param('address') address: string, ): Promise { if (address.substr(0, 2) !..