Part1: Forward notifications between StorIOSQLite v1 and v3

[nikitin-da]

Part of #875

[codecov-io]

Codecov Report

Merging #876 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #876      +/-   ##
============================================
+ Coverage     97.99%   98.01%   +0.01%     
- Complexity      815      819       +4     
============================================
  Files            98       99       +1     
  Lines          2787     2815      +28     
  Branches        308      310       +2     
============================================
+ Hits           2731     2759      +28     
  Misses           27       27              
  Partials         29       29

Impacted Files	Coverage Δ	Complexity Δ
...h/storio3/sqlite/interop1to3/StorIOSQLite1To3.java	100% <100%> (ø)	4 <4> (?)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b12beef...b6457f1. Read the comment docs.

[geralt-encore]

@nikitin-da @artem-zinnatullin Do you think that it is a good idea to have it? I mean a migration to a newer version shouldn't be hard and it is a lot of code to maintain and care about.

[nikitin-da]

@geralt-encore happy new year man! 🎄 🍾 🍊

[nikitin-da]

a migration to a newer version shouldn't be hard

I'm totally agree that migration of storio itself is not a big deal and can be done by single pull request.
But most likely we have to migrate to RxJava2 as well and here we can meet some problems if we use storio-rx widely.
My current project has no separate repository that can be fast converted to storio3 but keep outer interface on rx1 by RxJavaInterop. I guess I'm not alone in this problem and many projects will have to migrate storio and rx stepwise.

it is a lot of code to maintain and care about

Firstly I thought that some gist with notifications sharing will be enough. But lately realized that I have to migrate changes and mapping as well. It is not feet to gist and requires tests..
What about code maintaining I think to prevent induced changes in this module we may use fixed storio 3.0.0 version here instead of subproject dependency.
And than it will lead to separate interop version (because otherwise interop version will outrun storio itself).

Or maybe we should create another repository and publish it independently like it do @akarnokd.
@artem-zinnatullin any thoughts?

[geralt-encore]

@geralt-encore happy new year man! 🎄 🍾 🍊
Thanks, mate! Happy new year to you, too!

I see what problem you are trying to solve and it feels more like RxJava migration related than StorIO related. Also, it might get out of hand pretty fast. Imagine that we would release storio4 and 3 more migrations are needed.

I like the idea of keeping it in separate repo and publishing as an independent artefact.