현재 처리중인 블럭에 head가 위치해있을 때 state tree에서 조회하여 ledger를 바로 검색하는 함수인 findXXXLedgerFromHead 함수가 현재 처리중인 블럭을 찾지 않는다는 사실을 발견하여, 해당 과정을 추가하였습니다.
이 문제는 result의 처리값들을 바로바로 state tree에 반영하지 않고, 해당 블럭의 모든 처리를 끝낸 후 한꺼번에 반영해서 생깁니다. 자세한 사항은 맨 아래에 따로 쓰겠습니다.
1의 과정에서 ledger_type의 is_empty의 기본 생성값을 true로 변경하여, ledger_list[pid] 에서 pid에 대응하는 ledger가 존재하지 않아도 빈 ledger를 생성합니다. 따라서 is_empty가 true로 생성되어 존재하지 않는다는 리턴을 줄 수 있게 하였습니다.
ledger에서 동일 블럭에서 insert였던 ledger를 또다시 수정할 경우 update로 바꿔버리던 문제를 해결하였습니다.
up_block을 조회하여 해당 ledger가 현 블럭에서 생성된 경우, insert를 유지하도록 합니다.
getBlock이 블록 자체를 접근하는지 UnresolvedBlock을 접근하는지가 애매해서 정확하게 이름을 바꿨습니다.
user ledger, contract ledger, user cert, user attribute, contract 테이블의 insert, update 문을 정확히 수정하였습니다.
ledger에서 insert와 update가 혼재되는 경우가 있어서 ON DUPLICATE KEY UPDATE 문을 사용할까 했는데, 중복되는 unique key가 잘못 들어왔을 경우에도 오류를 내지 않고 수정해버리는 위험성이 존재할 것 같아서 querytype으로 sql문을 분기하였습니다.
user attribute는 현재로서는 모든 사항이 다 주어져야 작동 하는 것으로 스펙이 명시되어있어서 위험성이 없다고 판단되어 ON DUPLICATE KEY UPDATE를 사용하고 있습니다. 여기 또한 문제가 된다면 추후 query type를 명시해서 분기할 예정입니다.
TODO : 수정하다보니 chain_plugin의 result query를 처리하는 processTxResult 함수에서 unresolved block을 수정한 후 pool에 반영하는 부분이 없는것으로 보여, 수정이 필요합니다.
result의 처리값들을 바로바로 state tree에 반영하지 않고, 해당 블럭의 모든 처리를 끝낸 후 한꺼번에 반영하는 문제에 대하여
지금처럼 한꺼번에 처리할 경우: 한 블록에서 한 ledger에 여러 번의 변경이 있을 경우, 같은 pid에 대하여 여러 번의 state tree 갱신을 할 필요가 없습니다. 그 대신, ledger의 이전 값을 찾기 위해 이번 변경처럼 findXXXLedgerFromHead 함수에 현 블록의 ledger에 접근하는 동작이 추가됩니다.
쿼리마다 갱신할 경우: 같은 pid를 갖는 ledger가 여러 번 변경될 수 있습니다. 따라서 state tree에 그만큼 더 많이 접근합니다. 대신 findHead 함수가 state tree만 검색하면 되도록 간단해집니다.
참고사항 : state tree(binary tree)와 현 블록 ledger list 접근(map)의 오버헤드를 비교하려면 state tree는 모든 데이터를 가지고 있어야 하므로 블록 ledger list보다는 사이즈가 훨씬 커지는 것을 고려하세요.
변경 사항
현재 처리중인 블럭에 head가 위치해있을 때 state tree에서 조회하여 ledger를 바로 검색하는 함수인 findXXXLedgerFromHead 함수가 현재 처리중인 블럭을 찾지 않는다는 사실을 발견하여, 해당 과정을 추가하였습니다. 이 문제는 result의 처리값들을 바로바로 state tree에 반영하지 않고, 해당 블럭의 모든 처리를 끝낸 후 한꺼번에 반영해서 생깁니다. 자세한 사항은 맨 아래에 따로 쓰겠습니다.
1의 과정에서 ledger_type의 is_empty의 기본 생성값을 true로 변경하여, ledger_list[pid] 에서 pid에 대응하는 ledger가 존재하지 않아도 빈 ledger를 생성합니다. 따라서 is_empty가 true로 생성되어 존재하지 않는다는 리턴을 줄 수 있게 하였습니다.
ledger에서 동일 블럭에서 insert였던 ledger를 또다시 수정할 경우 update로 바꿔버리던 문제를 해결하였습니다. up_block을 조회하여 해당 ledger가 현 블럭에서 생성된 경우, insert를 유지하도록 합니다.
getBlock이 블록 자체를 접근하는지 UnresolvedBlock을 접근하는지가 애매해서 정확하게 이름을 바꿨습니다.
user ledger, contract ledger, user cert, user attribute, contract 테이블의 insert, update 문을 정확히 수정하였습니다. ledger에서 insert와 update가 혼재되는 경우가 있어서 ON DUPLICATE KEY UPDATE 문을 사용할까 했는데, 중복되는 unique key가 잘못 들어왔을 경우에도 오류를 내지 않고 수정해버리는 위험성이 존재할 것 같아서 querytype으로 sql문을 분기하였습니다. user attribute는 현재로서는 모든 사항이 다 주어져야 작동 하는 것으로 스펙이 명시되어있어서 위험성이 없다고 판단되어 ON DUPLICATE KEY UPDATE를 사용하고 있습니다. 여기 또한 문제가 된다면 추후 query type를 명시해서 분기할 예정입니다.
TODO : 수정하다보니 chain_plugin의 result query를 처리하는 processTxResult 함수에서 unresolved block을 수정한 후 pool에 반영하는 부분이 없는것으로 보여, 수정이 필요합니다.result의 처리값들을 바로바로 state tree에 반영하지 않고, 해당 블럭의 모든 처리를 끝낸 후 한꺼번에 반영하는 문제에 대하여
지금처럼 한꺼번에 처리할 경우: 한 블록에서 한 ledger에 여러 번의 변경이 있을 경우, 같은 pid에 대하여 여러 번의 state tree 갱신을 할 필요가 없습니다. 그 대신, ledger의 이전 값을 찾기 위해 이번 변경처럼 findXXXLedgerFromHead 함수에 현 블록의 ledger에 접근하는 동작이 추가됩니다.
쿼리마다 갱신할 경우: 같은 pid를 갖는 ledger가 여러 번 변경될 수 있습니다. 따라서 state tree에 그만큼 더 많이 접근합니다. 대신 findHead 함수가 state tree만 검색하면 되도록 간단해집니다.
참고사항 : state tree(binary tree)와 현 블록 ledger list 접근(map)의 오버헤드를 비교하려면 state tree는 모든 데이터를 가지고 있어야 하므로 블록 ledger list보다는 사이즈가 훨씬 커지는 것을 고려하세요.
state tree 확인
state tree 확인
3블럭
state tree 확인 270
어느 쪽이건 잘못된 구현은 아닙니다. 현재 구현은 일괄 갱신입니다.