Conversation
|
Similar problems in https://github.com/stellar/go/pull/5568 and #1 exist in this PR as well. TODO: fix it |
sydneynotthecity
left a comment
There was a problem hiding this comment.
High level, there are some quirks in stellar-etl. Now is the time for us to discuss whether it makes sense to incorporate back in to XDRill or not. Particularly:
- int vs real representation for asset amounts - should this stay in raw integer form? Should we convert to real? Offer both?
- Asset id - this is an optimization specific to Hubble. Does it make sense to create a more universal asset hash? If so, does
FarmHashmake the most sense? - buy vs sell side of offers. In Horizon, these are presented as
baseandcounterassets, where base asset hash < counter asset hash so that the trade pairs are consistently on the same side. This may be an opportunity for us to reimagine how we want this schema to be defined
ingest/ledger_operation.go
Outdated
ingest/ledger_operation.go
Outdated
There was a problem hiding this comment.
do we want to bring over this logic from stellar-etl? I think both RPC and horizon keep the raw stroop values to avoid floating point errors. wdyt of keeping amounts in stroops?
There was a problem hiding this comment.
Hmm that's fair. Less railroading people into floating point if they don't want ot
ingest/ledger_operation.go
Outdated
There was a problem hiding this comment.
nit: Should we be parsing asset consistent via addAssetDetails...?
There was a problem hiding this comment.
Let me take a look at this again. Might have just been stellar-etl never updated this or there was an actual reason for this
There was a problem hiding this comment.
Yeah so this is a type TrustLineAsset
type TrustLineAsset struct {
Type AssetType
AlphaNum4 *AlphaNum4
AlphaNum12 *AlphaNum12
LiquidityPoolId *PoolId
}
Note the extra LiquidityPoolId *PoolId
Whereas addAssetDetails only handles normal Asset types. I'll try to consolidate as I think they effectively want the same "asset" info
ingest/ledger_operation.go
Outdated
There was a problem hiding this comment.
nit: asset representation is different from manage buy/sell offer
ingest/ledger_operation.go
Outdated
There was a problem hiding this comment.
nit: copy/paste error. wrong operation type
Yeah I was debating this too. Thinking about it again I personally would lean towards addressing the quirks now. It means less refactoring in the future in favor of spending more time now. But I think it might be the right decision to defer for now. It's much easier to test and compare similar logic rather than slightly different logic. Like for refactor/testing of stellar-etl/processors/xdrill it'll be as easy as writing the new code and compare the output of old stellar-etl == new stellar-etl. I think the fewer value fixes we make will make the diffing much easier. Basically sticking with the status quo makes it easier for myself or anyone else to pick up later.
I agree with keeping this in the raw form instead of converted float
iirc the issue with the pure FarmHash is that it didn't fit nicely into the BigQuery integer size (64/128 bytes?) which is why some asset_ids can be negative because the BQ column for asset_id is int64 (?) instead of a long long type (128+). This is hacky. I'm not opposed to making this more standard and make more sense though
👍 Edit: So I went ahead and did make the int versus real amount change |
| @@ -0,0 +1,47 @@ | |||
| package ingest | |||
There was a problem hiding this comment.
Similarly to #3 (comment)
OperationDetails has been updated to structs to preserve strict typing for data instead of the the previous map[string]string/interface{}
There was a problem hiding this comment.
Oh also if anyone has better suggestions for organizing and what dir to put these files in I'm happy to update. One issue is that golang doesn't let you put these in a different directory and still have it as part of the same package (only files in the same dir can go in the same package) but if I separate these functions out to their own package I create a circular dependency with go/ingest
There was a problem hiding this comment.
How do we feel about making Parameters a straight JSON from xdr2json instead of our current ScVal parameter mess?
ingest/clawback_details.go
Outdated
There was a problem hiding this comment.
any and all amounts that exceed int32 need to be encoded as strings in the json
| Amount int64 `json:"amount"` | |
| Amount int64 `json:"amount,string"` |
| if ok { | ||
| invokeHostFunctionDetail.ContractCodeHash = contractCodeHash | ||
| } | ||
| case xdr.HostFunctionTypeHostFunctionTypeCreateContractV2: |
There was a problem hiding this comment.
Would be nice to combine V1 and V2 here since they're identical besides constructor
There was a problem hiding this comment.
Separated out the common parts to a new func in 0258c83
|
Closing this PR in favor of https://github.com/stellar/go/pull/5604 |
PR Checklist
PR Structure
otherwise).
services/friendbot, orallordocif the changes are broad or impact manypackages.
Thoroughness
.mdfiles, etc... affected by this change). Take a look in the
docsfolder for a given service,like this one.
Release planning
CHANGELOG.mdwithin the component folder structure. For example, if I changed horizon, then I updated (services/horizon/CHANGELOG.md. I add a new line item describing the change and reference to this PR. If I don't update a CHANGELOG, I acknowledge this PR's change may not be mentioned in future release notes.semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
github issue
xdrill functions for LedgerOperations
Why
Create low level helper functions for operations parsing
Known limitations