"Smart contracts can only read data that is part of the transaction or stored in blockchain state. To pass external data into a contract it will need to be sent via an oracle.
If you have an external application, such as a social media app, it can observe transactions and receive callbacks. You can either register a native plugin or you can poll eosiod. ...
I don't know if they are doing that, but what you could do is create a program that reads all blocks from start_block var:
Read block start_block
Check if this block has transactions
If yes, save the transactions in your database
Go back to step 1 and keep doing that till you are in the head block
Or, I already did it for you, just ...
I asked my friend Andrew Coutts this question on your behalf, and he said:
So the state history plugin is just a piece of the equation.
The history plugin exposes the RPC API that we're all familiar with.
The state history plugin saves state data to a new flat file format that’s designed to be read from external components and is faster to
Demux may help you!
you can watch specific contracts and actions, and handle this in light weight.
and see this example
have a good day :)
In the main repository there is a plugin called history_plugin which can serve as a good example and it includes a simple configurable filter for what it retains. A similar mechanism could be created to filter based on almost anything and its skeleton is a good resource for traversing the data structures you have access to as a plugin.
The option appears to have been introduced in v1.0.4, and it enables low-water marks for socket communication to minimise the number of send calls required to get a minimum number of bytes (i.e. enable faster communication.) However, this is not widely supported; poll(2) in Linux ignores SO_RCVLOWAT, but OS X may support it.
Both state_history_plugin and demux can be used to cache the contract action data into database/memory for fast access in a structured manner.
State_history_plugin is block.one recommended plugin that comes with eosio setup which can be used to cache the full block information (i.e. inline action data) in file.
nodeos -e -p ...
The solution is simple but obscure if you are not used to nodejs applications. Just run the application with the flag --max-old-space-size=8192
node --max-old-space-size=8192 fill.js
The issue is caused by blocks bigger than the application can handle by default. Since State Plugin downloads the whole block at once, the only way around is ...
Your method is right to find the answer of push_transaction by print logs,but the place is wrong.when we used command cleos push_transaction which call push_txn_func in cleos main.cpp,a better way to find this is:
1、find command in ../../cleos/main.cpp such as push_transaction
auto trx_result = call(push_txn_func, packed_transaction(trx, packed_transaction:...
It would help if you elaborated on what your "requirement" is as well as what "functions" are not being provided by the MongoDB plugin.
If you want to store actions to MongoDB, you could use demux to listen to the chain and then append your database of choice with the information.
there's a write-up on how exchanges should deal with deposits and withdrawals on the eos blockchain. It deals with irreversible blocks, might be useful: