#18 implement new strategy for database versions

[Christa Runge]

The new strategy for database versions is currently only a proposal.
iPhone release 1.5 is already in code freeze, so it will be implemented not before iPhone version 1.6.
As soon as we have a decision to implement this strategy, the following modifications are necessary:
a) iPhone already recognizes a future remote database version (SyncInfo line 165, getRemoteStatusFor, db_has_wrong_version). Nothing todo.
b) iPhone needs an additional indicator for a future remote version. Currently the indicator is the same as for a broken database, which is confusing.
c) iPhone: SynchInfo line 120, stepSyncDirectionForRemoteLocation needs to be analysed. It must refuse to select a download of a future database. Needs analysis.
d) iPhone already recognizes and rejects a future database version in the upgrade procedure (DBOverview line 198, upgradeDBFile). Nothing to do.
e) iPhone already rejects to open a future database version to calculate the learning data for today. Nothing to do.
f) iPhone already recognizes a future database version in the check if an upgrade is required (DBBasic line 123, DBFileRequiresUpgrade). Nothing to do.

g) Java Librarian: Synch list must include versions newer than the iPhone. The maxVersion parameter is then obsolete.
h) Java GuiList cell renderer: must indicate future database version.
i) all database action handlers except *.kdb import / export must refuse to work on future database versions.
j) with the new strategy we may assume that only one version of a database is in the inventory.
k) several simplifications will then be possible; e.g. the version parameter in the borrowDatabase method ...

[Christa Runge]

For a better assessment of the impact of a strategy change I did some tests (iPhone = svn 1899, Java = svn 1904):
1) patched a database to version 4 on the Java side. As expected, the server omits this database in the list request during the synch procedure. On the iPhone synch screen, it looks as if this database is not existing on the server.
2) modified the Librarian to include also higher versions in the sync list (according to the new strategy). Now the database is included in the list request. The iPhone recognizes it as future version and displays it as broken. => here we need a different icon, see (b) above.
3) the iPhone does not prevent the user from selecting this future database for download. => this must be corrected, see (c) above.
4) the iPhone performs the download request with its own version = 3 => this is correct (version = max. supported database version).
5) the server tries to borrow a version <= 3 from the Librarian. This fails as expected. As a consequence, the download fails. => this is perfect.

Note: In future, the server should still refuse to download a database with a higher version as the client.

[Christa Runge]

Issue (c) resolved in svn 1914. This will be included in iPhone release 1.5.x.

[Christa Runge]

Issue (b) resolved in svn 1917. This will be included in iPhone release 1.5.x.

[Christa Runge]

Ticket moved from /p/karatasi/features/88/