-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add nftoken_id
, nftoken_ids
and offer_id
meta fields into NFT Tx
responses
#4447
Conversation
nftokens_id
and offer_id
meta fields into NFT Tx responsesnftokens_id
and offer_id
meta fields into NFT Tx
responses
nftokens_id
and offer_id
meta fields into NFT Tx
responsesnftoken_id
, nftoken_ids
and offer_id
meta fields into NFT Tx
responses
Made some changes for improvements. This is ready for review again. |
e8e0d8b
to
74d149f
Compare
74d149f
to
ae58582
Compare
I'm curious why the goal for this was to iterate through the pages instead of using a bitwise operation to find the nftokenID and offerID? If a user has 500 pages you're going to iterate though all 500 when you could do this without iterating through a single page. Just curious |
@dangell7 could you elaborate how NFT ID could be fetched by bitwise for NFT transaction? AFAIK, NFT id isn't stored anywhere in the transaction data. Feel free to correct me if I misunderstood anything.
The change simply iterates the |
@shawnxie999 Here is the operation to create an NFTokenID. I'm pretty sure you have all these variables available where you are attempting to iterate through the pages. The offer can be done the same way. |
I have looked at it before. I believe we don’t have the NFT sequence param in the transaction data. I will double check tho |
@shawnxie999 I thought so too for the longest time. Its actually on the |
The |
@shawnxie999 The |
@dangell7 But then that would be similar to what this PR doing currently. Instead of iterating |
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.
In general a very nice job. I left a number of comments for your consideration. Please feel free to ask questions, or disagree, on any of the points I left.
This is ready for re-review. @scottschurr I appreciate the detailed feedback and explanations, thanks! |
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.
👍 LGTM. Thanks for putting up with my picky review.
//============================================================================== | ||
|
||
#ifndef RIPPLE_RPC_NFTOKENOFFERID_H_INCLUDED | ||
#define RIPPLE_RPC_NFTOKENOFFERID_H_INCLUDED |
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.
cc @scottschurr - is this the right directory for these files? it seems like this directory should contain implementations of RPC calls, not implementations of helpers, which is what these are to me.
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.
Regarding
is this the right directory for these files?
Good question, and something I was not thinking about during my review.
The best I can suggest is that we look at the placement of similar functionality. If we use the insertDeliveredAmount()
function as an example, then we see that the header file is in src/ripple/rpc
and the implementation is in src/ripple/rpc/impl
. So, if we follow that example, then these files are in the right places.
On the other hand, if we use the RPCHelpers
collection of utilities as our example, then we see that both the header and the implementation are in src/ripple/rpc/impl
. That would suggest the new header files should be moved down one level to src/ripple/rpc/impl
.
I don't personally have a strong opinion, since I don't play in this section of the code very often. I think it would be fine to leave these files where they are. But I'd also be fine if both the headers and implementation files were in impl
. There may also be other viable ways of organizing the files.
// We expect NFTs to be added one at a time. So finalIDs should be one | ||
// longer than prevIDs. If that's not the case something is messed up. | ||
if (finalIDs.size() != prevIDs.size() + 1) | ||
return std::nullopt; |
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.
cc @scottschurr - i haven't seen the use of std::nullopt
in our codebases, instead seeing just {}
. IMO we should stick with what is used elsewhere.
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.
@ledhed2222, that's a fair question. As a sanity check I just tried
grep -r -o std\:\:nullopt src/ripple | wc -l
That gave me over 250 hits of uses of std::nullopt
in the code base.
Personally, I usually prefer things like std::nullopt
over {}
because when I read the source code (as text) I know what they are. {}
can be anything with a default constructor. But I also know not everyone agrees with me.
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 think ill go with nullopt
. rippled does use it fairly common
// Find the first NFT ID that doesn't match. We're looking for an | ||
// added NFT, so the one we want will be the mismatch in finalIDs. | ||
auto const diff = std::mismatch( | ||
finalIDs.begin(), finalIDs.end(), prevIDs.begin(), prevIDs.end()); |
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.
why the change from std::set_difference
to std::mismatch
?
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.
@ledhed2222, here's a link to the motivation: #4447 (comment)
I get stuff wrong, so the choice is open for discussion.
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 think mismatch
would work since there is at most one NFT changed
7c60913
to
ce66dfd
Compare
resolved conflicts |
/** | ||
Adds common synthetic fields to transaction-related JSON responses | ||
|
||
@{ |
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.
is this @{
here on purpose?
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.
It looks like the intention is to provide Doxygen markdown. Perhaps this documents the intent: https://www.doxygen.nl/manual/commands.html#cmdaddtogroup
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.
this format is from the deliveredAmount file, so i just followed the same format
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.
are we using doxygen markdown in this repo? if so are the generated docs hosted somewhere?
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.
There have been people who were excited about Doxygen years ago. Certainly any Doxygen generated from the current source code is going to be very spotty. My past experience with Doxygen is it takes a lot of dedication to make truly useful Doxygen documentation. I don't think that level of effort has ever gone in. It's certainly not happening right now.
Speaking only for myself I'd be fine if all of the Doxygen markdown were removed. But I don't object to it being present either.
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 think leaving it wouldn't really matter.
and NFTokenCancelOffer transactions. | ||
|
||
Helper functions are not static because they can be used by Clio. | ||
@{ |
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.
is this @{
here on purpose?
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.
few comments
ready to m erge |
nftoken_id
, nftoken_ids
and offer_id
meta fields in transaction parsers
ripple/explorer#708
Awaiting this one. Any updates on tentatively when this can be merged to master? |
@smitha-d this change has already been released in v1.11. i think @intelliot would have a better idea on this. |
Correct - this was merged to master earlier this week, and was released in version 1.11.0. See the docs for how to install or update. |
When will version 1.11.0 start reflecting in mainnet (https://livenet.xrpl.org/) |
1.11.0 is a client version, not a network version (there are no network versions, but the protocol is defined by the amendments that are active). If you run your own node, then the updated API is available to you as soon as you update to 1.11.0. If you use public servers, it depends on when the operator updates their nodes. You can call server_info to learn more about the rippled server you're connecting to. It is worth noting that not all operators expose the rippled API, as many are beginning to deploy Clio API servers to handle client requests. Furthermore, some operators (like xrplcluster.com) use reverse proxies which can block certain requests, or modify certain responses - so the public API may differ from what is implemented in rippled itself. |
…ion parsers (#1018) ## High Level Overview of Change utilize added ID fields based on [this rippled PR](XRPLF/rippled#4447), rather than manually parsing for NFToken transactions. ### Context of Change #708
High Level Overview of Change
Added new metadata fields into
tx
andaccount_tx
responsesnftoken_id
fieldAdded a new field
nftoken_id
into the responses ofNFTokenMint
andNFTokenAcceptOffer
. This new field shows theNFTokenID
for theNFToken
that changed on the ledger as a result of the transaction.nftoken_ids
fieldAdded a new array field
nftoken_ids
into the response ofNFTokenCancelOffer
. This new field shows all theNFTokenID
s for theNFToken
s that changed on the ledger as a result of the transaction.offer_id
fieldAdded a new
offer_id
field into the response of aNFTokenCreateOffer
to show the OfferID of the newNFTokenOffer
.(Credit to @ledhed2222 for providing code from clio to extract NFTokenIDs from mint transactions.)