pocketnetteam / pocketnet.core

Decentralized social network based on the blockchain
https://pocketnet.app
Apache License 2.0
115 stars 28 forks source link

Divide PocketExplorerRpc::GetAddressTransactions into incoming/outgoing transactions #469

Closed andyoknen closed 1 year ago

andyoknen commented 1 year ago

Working branch

0.21

Description problem

Now PocketExplorerRpc::GetAddressTransactions method uses a fixed query to the database in the ExplorerRepository::GetAddressTransactions

https://github.com/pocketnetteam/pocketnet.core/blob/5f33ad7bacad2a82031dff8ac760cd59524f4089/src/pocketdb/web/PocketExplorerRpc.h#L27

https://github.com/pocketnetteam/pocketnet.core/blob/5f33ad7bacad2a82031dff8ac760cd59524f4089/src/pocketdb/repositories/web/ExplorerRepository.h#L39

This request takes into account transactions:

A -> A
B -> A
A -> B
  -> A

This request does not take into account transactions:

A -> B

A and B in this case are the addresses from which or to which funds are transferred

Possible solution

We could add an argument to API - direction - input or output to be used as a filter in the repository. In the first case, it is necessary to display all transactions in which the specified address is the source. In the second case, everything where the address is the recipient.

The working time of the method should not exceed 100ms

Additional task

Add an array argument to implement a filter by transaction types https://github.com/pocketnetteam/pocketnet.core/blob/5f33ad7bacad2a82031dff8ac760cd59524f4089/src/pocketdb/models/base/PocketTypes.h#L53-L96

DB Migration

https://github.com/pocketnetteam/pocketnet.core/blob/0.21/src/pocketdb/migrations/main.cpp

andyoknen commented 1 year ago

https://github.com/pocketnetteam/pocketnet.core/issues/387

lostystyg commented 1 year ago

May the solution in commit above be better than requested one?

andyoknen commented 1 year ago

@lostystyg Does it work fast? This will solve the main problem that the explorer does not show some transactions. I think we can add additional functionality for filtering operations through an additional issue

lostystyg commented 1 year ago

@andyoknen it will require some further optimization because currently it has scan Chain using covering index in its query plan but on testnet at 400k height it performs in arount 100ms. The division of this union for two different queries (as requested) will perform slower i assume, especially in case where we need to collect both inputs and outputs. So i think that above solution is better in case we do not explicitly divide inputs and outputs on the client side