Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • hive hive
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 86
    • Issues 86
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 23
    • Merge requests 23
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • hive
  • hivehive
  • Issues
  • #151

Closed
Open
Created May 05, 2021 by arcange@arcangeDeveloper

Standardization of block retrieval

Currently we have 6 different functions to retrieve information from blocks:

  1. block_api.get_block
  2. block_api.get_block_range
  3. condenser_api.get_block
  4. condenser_api.get_ops_in_block
  5. account_history_api.get_ops_in_block
  6. account_history_api.enum_virtual_ops

With few exceptions, they each have a different parameters format and provide different results (structure, format, ...).

[1,2,3] do not return vops
[4,5] return ops and/or vops but not block data [6] returns vops but not ops nor block data [1,2] return tx ids as a global array
[3] returns tx ids as a global array and inside transactions objects (the latter is easier to manage) [6] returns tx ids in each operation object [4] returns result as an array
[5] returns result is an object containing an array
[6] is the only one to effectively return operation_id

Properties like block_num, timestamp are sometimes duplicated in each transaction/operation which increases the volume of data returned and transferred.
Some APIs return operation type with the _operation suffix, some not. ... and so on

Couldn't we optimize all this by providing one API call and above all standardize how data are returned?

get_block_range looks like the favorite candidate to me.
It is quite new, less used up to now, and therefore less prone to break things if we change it.
My wish is it could return vops and has transactions_ids in each transaction object instead of being grouped in an array at the end.

Edited May 05, 2021 by arcange
Assignee
Assign to
Time tracking