Skip to content
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

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

dreacot
Copy link
Contributor

@dreacot dreacot commented Jul 21, 2022

This PR moves all DCR related methods and data structure into it's own dcr package, assets are now located under the wallets package.

@dreacot dreacot force-pushed the dcr_package branch 2 times, most recently from cc76042 to a649063 Compare July 21, 2022 22:58
@dreacot dreacot marked this pull request as ready for review July 28, 2022 22:55
@dreacot dreacot changed the title move dcr related functionlaity to it's own package move dcr related functionality to it's own package Jul 28, 2022
Copy link

@dmigwi dmigwi left a 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.

  1. 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.
  2. 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.
  3. 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)
Copy link

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.

Copy link
Contributor Author

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
Copy link

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))
Copy link

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)
Copy link

@dmigwi dmigwi Aug 12, 2022

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)

Copy link
Contributor Author

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)
Copy link

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.

Copy link
Contributor Author

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())
Copy link

@dmigwi dmigwi Aug 12, 2022

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)
Copy link

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()

Copy link
Contributor Author

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)
Copy link

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.

Copy link

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.

Copy link

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
Copy link

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?

Copy link
Contributor Author

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,
}
Copy link

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.

dreacot added a commit to song50119/dcrlibwallet that referenced this pull request Aug 15, 2022
…et to

hold mutiple assets, fix crash while creating a wallet
dreacot added a commit to song50119/dcrlibwallet that referenced this pull request Aug 18, 2022
…et to

hold mutiple assets, fix crash while creating a wallet
Copy link

@dmigwi dmigwi left a 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!

Copy link
Contributor

@itswisdomagain itswisdomagain left a 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) {
Copy link
Contributor

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".

Copy link
Contributor

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.

Copy link
Contributor Author

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
Screenshot from 2022-08-23 19-47-46

also do you think it's remotely possible we might want to be using different database drivers for different coins?

Copy link
Contributor

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.

Comment on lines +34 to +39
DbDriver string
RootDir string
DB *storm.DB

blocksRescanProgressListener BlocksRescanProgressListener
accountMixerNotificationListener map[string]AccountMixerNotificationListener
ChainParams *chaincfg.Params
Assets *Assets
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Screenshot from 2022-08-26 16-29-46

assets would need to be if we are going to access it's fields

Comment on lines +70 to +73
DBDriver string
RootDir string
DB *storm.DB
ChainParams *chaincfg.Params
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Screenshot from 2022-08-26 15-47-46

Copy link
Contributor Author

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)
Copy link
Contributor

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)
Copy link
Contributor

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.

Copy link
Contributor Author

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

@dreacot
Copy link
Contributor Author

dreacot commented Aug 26, 2022

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.

Previous implementation didn't make room for adding to the multiwallet wallets list

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants