[FIX] Migrate TransactionDao calls to TransactionRepository part - 1

[rishi2062]

Pull Request (PR) Checklist

Please check if your pull request fulfills the following requirements:

• The PR is submitted to the main branch.
• I've read the Contribution Guidelines and my PR doesn't break the rules.
• I've read and understand the Developer Guidelines.
• I confirm that I've run the code locally and everything works as expected.
• 🎬 I've attached a screen recoding of the changes.

Tip: drag & drop the video to the PR description.

What's changed?

Describe with a few bullets what's new:

• a
• b
• c

💡 Tip: Please, attach screenshots and screen recordings. It helps a lot!

Risk Factors

What may go wrong if we merge your PR?

• a - Maybe Some db calls inconsistency due to change between toEntity(), toLegacy(), toDomain() etc
• b

In what cases your code won't work?

• a
• b

Does this PR closes any GitHub Issues?

Check Ivy Wallet Issues.

• Closes Migrate TransactionDao calls to TransactionRepository #3132

Replace ISSUE_NUMBER with the number of the GitHub issue that this PR is fixing. If you've done that correctly, you'll see the issue title linked when previewing your PR description.

!Note: Do not link the PR number. Link the number/id of the GitHub Issue from issues.

Troubleshooting CI failures ❌

GitHub Actions failing? Read our CI Troubleshooting guide.

[rishi2062]

Hey @ILIYANGERMANOV , some more changes are there including test, but i wanted your comments, whether my procedures are correct.
Note : I have made sure not to hinder domain layer with any legacy data type return methods, so in the ui i am changing the returns wherever it is being required.

[ILIYANGERMANOV]

Overall looks like a step in the right direction. Left some comments that must be addressed

[rishi2062]

Hi @ILIYANGERMANOV , i stuck up with one issue, in BackupUseCaseTest , in that json needs to import 117 data, but it is importing 0 and that making the unitTest failed.
potential case might be due to savMany() improper handling, i can try to bypass that run, but any other solutions?

[rishi2062]

@ILIYANGERMANOV when we are using flagDelete, basically we are only changing isDeleted reference in db,
but when we are calling it delete, it is getting removed completely.
So this is what we are looking for?

[ILIYANGERMANOV]

@ILIYANGERMANOV when we are using flagDelete, basically we are only changing isDeleted reference in db, but when we are calling it delete, it is getting removed completely. So this is what we are looking for?

Yup, exactly 💯 We no longer have cloud sync to keep the record in DB. So let's just remove it

[rishi2062]

@ILIYANGERMANOV when we are using flagDelete, basically we are only changing isDeleted reference in db, but when we are calling it delete, it is getting removed completely. So this is what we are looking for?

Yup, exactly 💯 We no longer have cloud sync to keep the record in DB. So let's just remove it

Cool then, i have already done the changes for this. So we can consider this as a final commit for transaction Migration, if any changes required ping me.

[rishi2062]

Thanks @ILIYANGERMANOV , got some good explanation on why exactly we need to do some implementation in a specific way😁.