-
Notifications
You must be signed in to change notification settings - Fork 41
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
move dcr related functionality to it's own package #257
base: master
Are you sure you want to change the base?
Conversation
cc76042
to
a649063
Compare
- uncomment some multiwallet method and convert then to wallet methods
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 still new around and I am yet to understand the best practices recommended on this project. Below are my two cents after reviewing the code.
- Most newly added functions don't have descriptive comments on what the underlying code does. This becomes harder to evaluate if the specific function has all the necessary implementations without any extras.
- Variable names are overly descriptive making them too long. This makes most simple implementations break the standard 80 characters a line thus the code is less legible and harder to identify errors/bugs.
- Variables and functions chaining inside several structs feels excessive on most instances
rootDir = filepath.Join(rootDir, netType, "dcr") | ||
err := os.MkdirAll(rootDir, os.ModePerm) | ||
if err != nil { | ||
return mwDB, "", errors.Errorf("failed to create dcr rootDir: %v", err) |
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.
Since mwDB
is not assigned, wouldn't it be easier to return nil
.
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.
returning nil would give you an error in that instance which is why I initialized an empty instance at the top
) | ||
|
||
func initializeDCRWallet(rootDir, dbDriver, netType string) (*storm.DB, string, error) { | ||
var mwDB *storm.DB |
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.
you could drop this and instead make the following change at line 30.
return mwDB, "", errors.Errorf("failed to init dcr logRotator: %v", err.Error()) | ||
} | ||
|
||
mwDB, err = storm.Open(filepath.Join(rootDir, walletsDbName)) |
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.
mwDB, err := storm.Open(filepath.Join(rootDir, walletsDbName))
wallet.blocksRescanProgressListener.OnBlocksRescanStarted(walletID) | ||
} | ||
|
||
progress := make(chan w.RescanProgress, 1) |
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.
Isn't this as the same as making a non-buffered channel?
i.e. progress := make(chan w.RescanProgress)
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.
as of now, i'm not writing any new code, i just moved all the old code into a package, perhaps we can consider this during a code cleanup
} | ||
|
||
progress := make(chan w.RescanProgress, 1) | ||
go wallet.Internal().RescanProgressFromHeight(ctx, netBackend, startHeight, progress) |
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 is the potential of a panic if wallet.Internal()
returns a nil wallet instance.
Here is the culprit.
func (wallet *Wallet) Internal() *w.Wallet {
lw, _ := wallet.loader.LoadedWallet()
return lw
}
It returns a new wallet instance instead of updating the old one with the latest changes.
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.
as of now, i'm not writing any new code, i just moved all the old code into a package, perhaps we can consider this during a code cleanup
return 0 | ||
} | ||
|
||
_, height := wallet.Internal().MainChainTip(wallet.ShutdownContext()) |
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.
Does making two calls to wallet.Internal()
make any difference here?
ctx := wallet.ShutdownContext() | ||
_, height := wallet.Internal().MainChainTip(ctx) | ||
identifier := w.NewBlockIdentifierFromHeight(height) | ||
info, err := wallet.Internal().BlockInfo(ctx, identifier) |
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.
Here you've made 3 calls to wallet.Internal()
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.
same comments as above
w.handlePeerCountUpdate(peerCount) | ||
}, | ||
PeerDisconnected: func(peerCount int32, addr string) { | ||
w.handlePeerCountUpdate(peerCount) |
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 is really confusing how PeerConnected
and PeerDisconnected
execute the same function with no changes to inputs. It be easier to just execute one since both of them might not return any difference.
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.
reducing this unnecessary calls would reduce the number of mutex blocks requested especially on functions that require mutex blocks.
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.
Also if only you exported all those functions in type Notification struct{}
, this whole implementation wouldn't be necessary that is unless there is something I am missing out on.
w.syncData.activeSyncData.cfiltersFetchProgress.totalFetchedCFiltersCount += endCFiltersHeight - startCFiltersHeight | ||
|
||
totalCFiltersToFetch := w.getBestBlock() - w.syncData.activeSyncData.cfiltersFetchProgress.startCFiltersHeight | ||
// cfiltersLeftToFetch := totalCFiltersToFetch - w.syncData.activeSyncData.cfiltersFetchProgress.totalFetchedCFiltersCount |
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 presume this commented code is useless, why not delete it?
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.
thanks for pointing out, should be uncommented
GeneralSyncProgress: &GeneralSyncProgress{}, | ||
addressDiscoveryStartTime: -1, | ||
totalDiscoveryTimeSpent: -1, | ||
} |
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.
Where addition is conducted later on this -1
default values should be compensated later on to avoid misrepresenting the actual figures.
…et to hold mutiple assets, fix crash while creating a wallet
…et to hold mutiple assets, fix crash while creating a wallet
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.
Since no major code changes happened, this can go in as it is!
Great work in getting this done this fast!
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.
First pass; initial thoughts.
In addition to these, I've also not seen how to create a new dcr wallet or restore from seed and add the wallet to the multiwallet's list of dcr wallets. I was expecting to see something like mw.AddDcrWallet
that creates or restores a dcr wallet and adds it to the multiwallet's list of wallets.
"github.com/planetdecred/dcrlibwallet/wallets/dcr" | ||
) | ||
|
||
func initializeDCRWallet(rootDir, dbDriver, netType string) (*storm.DB, string, error) { |
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 doesn't really initialize a dcr wallet; the databases initialized here aren't specifically used for a single dcr wallet, one is used to store multiwallet data including ALL (dcr) wallets info and also general, non-wallet specific config data. This is really actually initializing the multiwallet. It also even initializes the log rotator which is not tied to any wallet in particular but is meant for all logging done by this library. I'd say let's move the body of this function back to the NewMultiwallet
function, and also retain the rootDir without appending "dcr".
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 suppose we'd need a function like this in the dcr package, perhaps a InitializeWallet
function so it reads as dcr.InitializeWallet
. I'm not yet completely sure what the dcr.InitializeWallet
function would do but it would be quite similar to what we have here. It wouldn't/shouldn't initialize a new log rotator though, the caller of the function should provide a logger to use. It also likely won't need to init a politeia database since politeia data won't be stored per wallet.
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.
appending "dcr" enables us keep all dcr database files under a single folder and seems easier to manage/track. I agree the method name is icky, and doesn't properly describe what's going on.
having separate rootdir for different assets looks advantageous in terms of folder structure
also do you think it's remotely possible we might want to be using different database drivers for different coins?
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.
having separate rootdir for different assets looks advantageous in terms of folder structure
I agree. What I was getting at is, the databases created here aren't even for all dcr wallets alone but for all wallets. It's the multiwallet parent database that tracks ALL wallets for all assets, which is used to populate/restore all the asset wallets when multiwallet is initialized. It also stores general config values that aren't related to any wallet.
The "dcr" subfolder should be reserved for dcr wallet databases, as in your screenshot. But there should also exist in the rootDir, a multiwallet.db file (currently called wallets.db, as in storing info for all wallets, which makes sense too).
do you think it's remotely possible we might want to be using different database drivers for different coins?
Yes. Very possible.
DbDriver string | ||
RootDir string | ||
DB *storm.DB | ||
|
||
blocksRescanProgressListener BlocksRescanProgressListener | ||
accountMixerNotificationListener map[string]AccountMixerNotificationListener | ||
ChainParams *chaincfg.Params | ||
Assets *Assets |
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.
Do these properties NEED to be exported? They were private properties.
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.
DBDriver string | ||
RootDir string | ||
DB *storm.DB | ||
ChainParams *chaincfg.Params |
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.
These aren't set or used yet. Can be removed till if and when they're needed.
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 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.
db driver is not used, would remove that, the others are being used
|
||
// init database for saving/reading proposal objects | ||
err = mwDB.Init(&Proposal{}) | ||
dcrDB, dcrRootDir, err := initializeDCRWallet(rootDir, dbDriver, netType) |
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.
Related to my first comment, this db isn't a dcrDB; it's a multiwallet db and should use the rootDir without appending "dcr"
. This db would track all wallets for all assets but the individual wallet dbs would be in the asset subfolders.
SetLogLevels(logLevel) | ||
|
||
// initialize Politeia. | ||
wallet.NewPoliteia(politeiaHost) |
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.
wallet.NewPoliteia returns some values that currently ignored.
Also, politeia shouldn't be a wallet construct - it's not tied to any one wallet. It should be much like the internal/vsp
package that is pretty much standalone but can work with any provided dcr wallet.
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.
that true, also i agree we shouldn't have politeia as a wallet struct, current problem is that politeia is now a wallet property, viewable when a dcr wallet is opened, and each dcr wallet can have it's own specific settings in regards to politeia.
but with the new internal politeia package that was merged, we'd have to take away this code anyways
Previous implementation didn't make room for adding to the multiwallet wallets list |
This PR moves all DCR related methods and data structure into it's own
dcr
package, assets are now located under thewallets
package.