-
-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: flatten the query dataframe for contracts #2196
Closed
johnson2427
wants to merge
2
commits into
ApeWorX:main
from
johnson2427:feat/flatten_query_dataframe
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So originally my idea was that
"*"
or specific event arg names mentioned in the columns would go grab those fields from the logs specifically, and really only ifevent_arguments
was present in the columns would you keep it, otherwise it should be flattened in the resulting dataframeThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I went through all of Ape, trying to find a good place to make this manipulation, and it looked pretty painful. I tried to do make this happen earlier, but there is no information available for what those dict keys are going to be in the
event_arguments
field. I can't know until we make the queryThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the comment not correct then? I would think unless
event_arguments
is in the request, we should flatten that fieldThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was flattening it either way. If you want:
I planned to flatten
event_arguments
. We don't have to though, wasn't sure if we wanted to always flatten it or notThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's good to think through the scenario where one of the event arguments might be called
name
or something else that ContractLog hasThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
contract_address
is the one that usually bites me... I always mix up if it the one on ContractLog or a custom event inputThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something I was contemplating here. If that were to happen, pandas will automatically rename both columns to name_x, and name_y.
Do we want to keep
event_arguments
in the columns names? In the case of the uniswap v2 contract, we'd getevent_arguments.token0, event_arguements.token1, event_arguments.pair, event_arguments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, it seems much more natural to me to work with it like this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't disagree, for this contract (UniswapV2), we do have an empty field. I think it's an ID? Maybe we just drop the empty field? Idk if we want that or not.
If we want the ability to query for sub-fields, it's going to take quite a bit of work. In
BaseContractLog
we have theevent_arguments
field as a dict. Since that field can be anything depending on the contract, I believe we'd need a model_validator in that model where we can pull apartevent_arguments
and set the keys of that value to keys of the model itself.I'm not 100% sure this will work, I've never created fields in a model on the fly before. But if it does, we'd have to ensure the downstream functionality remains intact. As long as we don't remove
event_arguments
we should be okay. Maybe we add something to the field names we create so we know those are generated fields? Not sure