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

BitcoinStore - Complete Refactoring of Data Storing #1405

Merged
merged 111 commits into from May 20, 2019

Conversation

Projects
3 participants
@nopara73
Copy link
Collaborator

commented May 4, 2019

This pull request aims to completely refactor how we store data on the disk, because since the inception of Wasabi many snap decisions and hacks were made regarding this topic.

The first version of this only elevates out how we store the Index file and nothing more. The basic idea is that we have a BitcoinStore class, which will contain various subclasses like IndexStore, BlockStore, WalletStore, etc...

This'll enable us to efficiently and cleanly cache data, that would result in a faster user experience, to load and watch multiple wallets simultaneously and to safely read-write from the disk, while trying to avoid data corruption.

nopara73 and others added some commits May 3, 2019

Fix ReorgTestAsync. (#5)
Fix ReorgTestAsync.
@lontivero

This comment has been minimized.

Copy link
Contributor

commented May 5, 2019

This is inspiring. I will come from dead my dataStore PR and finish it, it has been waiting for a year now.

nopara73 and others added some commits May 5, 2019

molnard and others added some commits May 6, 2019

Tests for IoManager class. (#6)
Tests for IoManager class.
{
using (CoinJoinsLock.Lock())
using (await CoinJoinsLock.LockAsync())

This comment has been minimized.

Copy link
@lontivero

lontivero May 19, 2019

Contributor

It could worth to replace the List<uint256> by an ImmutableList<uint256> in order to eliminate the need for these locks and async locks.

This comment has been minimized.

Copy link
@nopara73

nopara73 May 20, 2019

Author Collaborator

That doesn't eliminate the need for locks, similarly to the Concurrent Collections. Locks make sure that the data is consistent with the business logic. immutable/concurrent collections simply don't throw exceptions when writing or reading them from different threads.

This comment has been minimized.

Copy link
@lontivero

lontivero May 20, 2019

Contributor

ok

@@ -1,6 +1,7 @@
using System.Collections.Generic;
using System.Collections.Generic;

This comment has been minimized.

Copy link
@lontivero

lontivero May 19, 2019

Contributor

I think this is here because there were changes in this file that were removed later. Can be removed?

@@ -1,4 +1,4 @@
using System;
using System;

This comment has been minimized.

Copy link
@lontivero

lontivero May 19, 2019

Contributor

Same here, nothing really changed here.

nopara73 and others added some commits May 19, 2019

Merge pull request #16 from molnard/mutexcomment
Add comments to AsyncMutex.

@nopara73 nopara73 merged commit 72be178 into zkSNACKs:master May 20, 2019

1 of 4 checks passed

Wasabi.Linux in progress
Details
Wasabi.Osx queued
Details
Wasabi.Windows in progress
Details
CodeFactor No issues found.
Details

v1.1.5 automation moved this from In Progress to Done May 20, 2019

@nopara73 nopara73 deleted the nopara73:bitcoinstore branch May 20, 2019


public void DeleteMe()
{
if (File.Exists(OriginalFilePath))

This comment has been minimized.

Copy link
@lontivero

lontivero May 20, 2019

Contributor

This can fail in rare situations when the file exists when we ask but doesn't exist anymore when we request the deletion (the user could move the files or delete it). In case the OS locks the file this could raise an IOException. I think instead of doing the Tester-Doer we could try to delete it into a try-catch block.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.