-
Notifications
You must be signed in to change notification settings - Fork 159
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
SyncBucket cleanup #407
SyncBucket cleanup #407
Changes from all commits
58b189e
47d4978
c85aeff
7e503be
8730f37
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,7 +12,6 @@ pub use self::version::Version; | |
use integer_encoding::{VarIntReader, VarIntWriter}; | ||
pub use multihash; | ||
use multihash::{Code, Identity, Multihash, MultihashDigest}; | ||
use std::cmp::Ordering; | ||
use std::convert::TryInto; | ||
use std::fmt; | ||
use std::io::Cursor; | ||
|
@@ -43,7 +42,7 @@ pub struct Prefix { | |
} | ||
|
||
/// Representation of a IPLD CID. | ||
#[derive(Eq, Clone)] | ||
#[derive(PartialEq, Eq, Hash, Clone)] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It was intentional to keep those separate before (this was a fork of existing implementations initially) and the specific details of comparing and hashing bytes was necessary. I can't see at this point for that specific comparison (cids aren't used as Hamt keys and that was going to be the only potential need to be specific). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, could two CIDs ever be considered equal in one way but not in the other? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Equality, no, but ordering potentially yes because of the variant encoding. Just something to keep in mind in the future, that would be a very nuanced bug to find if there was an inconsistency (I mean, even without varints because the bytes are lexicographically sorted and not all codes are the same byte length) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So are you talking about ordering and not about There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hash will be different too, only PartialEq/Eq would be the same (sorry for bringing up order, was just looking on my phone) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But I don't think we use the cid hash for any consensus related things so should be fine. (Might be safe to keep that one until we have those specifics tested more in detail) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah yeah, the hash will be different, but as far as I understand you would never look at the resulting hash value anyway, or somehow rely on what it is – i.e. previously the hash of a cid was the hash of its bytes which as far as we're concerned could be anything There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I mean it could matter if you use a cid as the key to a hamt, but that shouldn't be a need in the near future because the go implementation statically uses bytes for their keys. I double checked, doesn't seem like there is an actual use for a consistent hash here, so good on my end sorry to sidetrack with this. I just wanted to make sure it didn't go quietly unconsidered There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will definitely keep this in mind for if we're ever going to use the CID as the key to a hamt |
||
pub struct Cid { | ||
pub version: Version, | ||
pub codec: Codec, | ||
|
@@ -203,30 +202,6 @@ impl Cid { | |
} | ||
} | ||
|
||
impl std::hash::Hash for Cid { | ||
fn hash<H: std::hash::Hasher>(&self, state: &mut H) { | ||
self.to_bytes().hash(state); | ||
} | ||
} | ||
|
||
impl PartialEq for Cid { | ||
fn eq(&self, other: &Self) -> bool { | ||
self.to_bytes() == other.to_bytes() | ||
} | ||
} | ||
|
||
impl PartialOrd for Cid { | ||
fn partial_cmp(&self, other: &Self) -> Option<Ordering> { | ||
self.to_bytes().partial_cmp(&other.to_bytes()) | ||
} | ||
} | ||
|
||
impl Ord for Cid { | ||
fn cmp(&self, other: &Self) -> Ordering { | ||
self.to_bytes().cmp(&other.to_bytes()) | ||
} | ||
} | ||
|
||
impl fmt::Display for Cid { | ||
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { | ||
let encoded = match self.version { | ||
|
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.
@dutterbutter Wasn't there a specific need for this? I remember vaguely it being written into the spec
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 vaguely remember us needing this at some point as well. Clearly not anymore?
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 recall the specific need for this, I think its fine to be removed.