-
Notifications
You must be signed in to change notification settings - Fork 3
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
Replace explorer prefix search with exact match for block and transaction hash #722
Conversation
1c221f5
to
03e9e2c
Compare
eb2b520
to
54e94c6
Compare
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.
@Ayiga can you confirm this will work with the block explorer?
LIMIT 5" | ||
); | ||
let block_query_rows = query(block_query.as_str()) | ||
.bind(&search_query_string) | ||
.fetch(self.as_mut()); |
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.
We can do LIMIT 1
and fetch_one
here, querying for blocks by equality on hash is only ever going to return one block
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.
yeah
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 am considering making the blocks field an Option<BlockSummary>
since there can only be one block now. However, I don't want to break the frontend, and I also think that SearchResult should be an enum
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.
Making this return an enum
would indeed be a backwards incompatible change. I can possibly support it with a backwards compatible decoder that can support either representation, but I think that would need to be in place in the Block Explorer client-side code before that sort of change is introduced on the server side.
I think this should be fine in terms of functionality at the moment. There is a slight change in the input requirements that may cause problems with the current version of the Block Explorer. That being the requirement of the input to be a But this is likely alright, as we'll want to change the Block Explorer's search behavior regardless so that it isn't submitting these requests when they don't conform to the |
Just tested this. The |
addresses https://github.com/EspressoSystems/espresso-block-explorer/issues/148
This PR:
String
toTaggedBase64