Closed Zerim closed 6 years ago
I feel it's too early for me to comment on this. I do like the idea though of generating a list/hierarchy of operations for processing instead of actually running the processing inside the mapping.
Okay, PR updated with some of my latest thoughts. I've gone all in on the declarative fluent API to build up a data structure which describes the projection mapping logic. No effects are computed while building up this data structure -- all computation is lazy. I'm going to get a few more examples under my belt and see how this approach holds up.
Since all this JS does is build a data structure (which itself acts a sort of DSL), it's an open question whether Query Nodes will ever execute the entire script, or if this is just something that developers would use locally to "compile" a DSL.
I added a mapping to for the District0x contract. It is still a WIP, but an example of what the API could look like.
There is really not much to the API other than the injected config variables, the injected contract instance, and the injected adapters (javascript clients for web3 and ipfs).
Most of the control uses RXJS, but the example could be reproduced using callbacks as well.
I added the early beginnings of a data source definition spec here: https://docs.google.com/document/d/1bJrNMKK1xOdCIHVDem_QDhSLThb7bZHm6u4ZnBxnJkU/edit#
LGTM 👍
I think we'll want to change the last event-source mapping proposal a little bit (remove rjxs
for instance). I'll submit a separate PR for these changes.
The "projection" approach requires that we have access to the solidity source code, or the compiled AST for the contract, so that we can provide a wrapper over the top level private variables.
StorageWrapper is used to wrap the contract storage so that we can chain map operations that feel natural to the developer, however, are actually executed lazily, This allows us to control execution in whichever way we see fit. This could open the door to performance operations (i.e. only iterating over values that have changed from one ethereum block to the next).
However, if a property in an entity is a reference to mutable data (i.e. an ipns link or another ethereum contract address), we would always need to reprocess all the operations in case the referenced data changed. Not sure yet how this would be detected and/or reflected in the API.
The output of this projection should be diffed against the output of the previous blocks projection so we are only storing the novelty for each entity on each new block.