search

bk138 / multivnc

MultiVNC is a cross-platform Multicast-enabled VNC viewer based on LibVNCClient. The desktop client runs on Unix, Mac OS X and Windows. There also is an Android client.
GNU General Public License v3.0
472 stars 67 forks source link

Android: Switch to Room #117

Closed gujjwal00 closed 3 years ago

gujjwal00 commented 3 years ago

Fixes #116 .

I have kept the current import/export logic as is( export only sqlite, import from either sqlite or xml) for now. We can switch to exporting xml after this lands.

bk138 commented 3 years ago

Nice work! This will take me some time to review and learn, but it's definitely the way to go.

bk138 commented 3 years ago

Given our recent conversation in #116, 588664c6714ae7ad2544b20812ce07153b1431ce should get reverted. Maybe take this into account here?

gujjwal00 commented 3 years ago

Maybe take this into account here?

Should we switch completely to xml? Or export to xml but import from both?

bk138 commented 3 years ago

Maybe take this into account here?

Should we switch completely to xml? Or export to xml but import from both?

I propose dropping binary export import again (was just in the beta anyway) and go for XML only.

gujjwal00 commented 3 years ago

So... XML doesn't seem to be full-proof either.

If we remove a column or add a not null column in future, importer will crash if given an old XML export. We will have to add a nullable column or modify the XML before passing it to importer.

But given that this is not an immediate problem and this PR is already too big, I will go for XML as you proposed.

Thinking about the binary dump: I think if we close all database connections, replace the sqlite file and reopen database our migration code (which we will have to add anyway if we ever change schema) will be triggered and we should be able to import old database. But there are still some issues with journal/wal files which will have to be resolved.