Use BLOB and consensus encoding for the entire header type#326
Use BLOB and consensus encoding for the entire header type#326rustaceanrob merged 2 commits intomasterfrom
BLOB and consensus encoding for the entire header type#326Conversation
rustaceanrob
force-pushed
the
header-db-4-7
branch
2 times, most recently
from
812379b to
a7cbc8a
Compare
rustaceanrob
force-pushed
the
header-db-4-7
branch
from
a7cbc8a to
c251c92
Compare
|
Alright, instead of purely going on "trust me bro" I did a quick benchmark. The header sync over signet with the new and old schema both took exactly 93 seconds. I checked I was on the proper branch for each and I was, so this change is neutral apparently. To make the case for why the schema should change, when migrating to a new SQL schema we can always add optional columns but we can't take them away without nuking the user's headers |
src/db/sqlite/mod.rs
Outdated
|
|
||
| pub(crate) const DEFAULT_CWD: &str = "."; | ||
| pub(crate) const DATA_DIR: &str = "data"; | ||
| pub(crate) const DATA_DIR: &str = ".light_client_data"; |
There was a problem hiding this comment.
Should this just be called kyoto or something? Might be a little vague for a user to track down what is writing to this (unless I am missing some namespace). The . also makes this a little less cross platform friendly, since I don't think it's a windows convention to hide files/directories like that. On unix-like systems, it might be nice to use some XDG conventions too.
There was a problem hiding this comment.
Wasn't aware . doesn't play nice with Windows. I don't think we need to go full XDG because the intention is this directory stores the bitcoin/signet/testnet data for the light client in an arbitrary location. The developer is then responsible to throw that into an appropriate spot (different for iOS/Ubuntu etc.).
My opinion against using kyoto names is the user somehow has to know their wallet "X" uses a repository called "kyoto" on Github to make sense of that directory. Anything with "light client" at least hints that there is data stored that underpins their wallet
There was a problem hiding this comment.
fwiw I think XDG integration would be pretty light touch, like just checking for a XDG_DATA_HOME env var and using it if it's there. But I see the point of the wallet app doing that and then passing a path to its internal kyoto to write to (e.g. $HOME/.local/share/fancy-wallet/kyoto.
And if the intention is for the outer wallet to namespace this on the filesystem (the $HOME/.local/share/fancy-wallet/ part), I guess the name of this directory is less important since should really only be cared about by the wallet developer. Thinking from their perspective, I guess I wouldn't care much what it's called as long as I wasn't surprised at some point "wtf is this random data dir".
There was a problem hiding this comment.
Dropped the . prefix in 008cb2b
There's not much of a reason to hide this directory anyway, all the data is public via p2p gossip.
And if the intention is for the outer wallet to namespace this on the filesystem
Yeah, this is the intention. The developer is responsible for where they would like this to go. This crate shouldn't make any opinions about absolute paths.
rustaceanrob
force-pushed
the
header-db-4-7
branch
from
c251c92 to
358bb1d
Compare
2 participants
Building on #324, the header schema is tragically implemented considering
Headeris serializable and each component part can be recovered as required. I don't think theBLOBtype can't be divided efficiently even if we know it will always be 80 bytes, but after this update the change seems noticeably faster on my end. Not even sure caching is urgent, it seems to pretty much rip. Almost comical how much simpler this is yet seemingly faster.