Don't use <0.56 and 0.60

[xnview]

If you try to use 0.56 or older, AND 0.60 with same database, your database will be strange!

[m.Th.]

If you try to use 0.56 or older, AND 0.60 with same database, your database will be strange!

From now on, look in each version of the program look at the expected version number of the DB. And if the expected version is smaller than the version of the DB then throw an error ("Database has a more recent version number than the expected one") and go out.

[oops66]

Hello,
.... In this case, it's safer to rename the DBs files (for each versions in case of DB changes) ?
XnView.db ---> XnView_v0.60.xndb
Thumb.db ---> Thumb_v0.60.xndb

[m.Th.]

Hello,
.... In this case, it's safer to rename the DBs files (for each versions in case of DB changes) ?
XnView.db ---> XnView_v0.60.xndb
Thumb.db ---> Thumb_v0.60.xndb

It is more complicated because there are references to the current file(s) path etc. Also, the newer version must upgrade any of the older versions, hence a continuous name change per version would be difficult to handle.

[oops66]

... Yes, not so easy to do, but it would be probably better during the MP beta stage - IMHO. But a least, change the name : "XnView.db" ... because it was the unique and previous DB name (at MPv0.56 and before). ?

[m.Th.]

... Yes, not so easy to do, but it would be probably better during the MP beta stage - IMHO. But a least, change the name : "XnView.db" ... because it was the unique and previous DB name (at MPv0.56 and before). ?

To change the name to xnview.xndb - sure. I explained somewhere else, as you know.

For beta stage... WHAT beta stage???

We are in beta isn't it?

...but I think that's better to have the possibility to have different configurations for different installations of XnViewMP. This will serve not only for internal beta stage but also for different other purposes.

For example one can have in c:\program files\xnview\ the 'official', stable version which will point to c:\foo\xnview.db while in c:\downloaded\test\xnview\ the latest cutting-edge build which will point to xnview.xndb located in the very same directory.

However we must think how/where to persist the settings for each XnViewMP installation.

A draft idea would be something like this:

Code: Select all

cHome = ExtractFilePath(Application.ExeName);

if (not FileExists(cHome+'xnview.ini'))
{
  //...look for xnview.ini in the default user folder
}

IOW, if an xnview.ini exists in the application's root then this will take precedence in front of the official, central (shared) one.

Any other ideas?

[xnview]

...but I think that's better to have the possibility to have different configurations for different installations of XnViewMP. This will serve not only for internal beta stage but also for different other purposes.

It's already possible, XnViewMP check first in the same folder for a .ini

[helmut]

It's typical during a software lifecylce that database modifications are needed. Typical handling for this is:
- Introduce a database version.
- Newer XnView versions can update from any old database version to the current version. This is performed by applying all version updates one after another that happened between versions.
E.g.
XnView 0.55 has DB version 0.1 and can create a version 0.1 database from scratch.
XnView 0.56 has DB version 0.1 and can create a version 0.1 database from scratch.
XnView 0.60 has DB version 0.2 and can create a version 0.2 database from scratch. In addition, it can update a database from 0.1 to 0.2 (if needed)
XnView 0.61 has DB version 0.2 and can create a version 0.2 database from scratch. In addition, it can update a database from 0.1 to 0.2 (if needed)
XnView 0.80 has DB version 0.3 and can create a version 0.3 database from scratch. In addition, it can update from 0.1 to 0.2 and from 0.2 to 0.3 (if needed).
..

- Older XnView versions will ouput a message if their supported database version is older than the current version.

[oops66]

...XnView 0.80 has DB version 0.3 and can create a version 0.3 database from scratch. In addition, it can update* from 0.1 to 0.2 and from 0.2 to 0.3 (if needed)...

- Older XnView versions will ouput a message if their supported database version is older than the current version.

+1 , I agree (... *update, or better: duplicate) to keep the ability to use the previous XnViewMP versions, it's that why IMHO than a new name for the DB file is better, for a new BD_Version...
(Ex: XnView_v0.3.xndb and Thumb_v0.3.xndb)

XnView 0.80 has DB version 0.3 and can create a version 0.3 database from scratch. In addition, it can update or duplicate from 0.1 to 0.2 and from 0.2 to 0.3 (if needed)...

[m.Th.]

It's typical during a software lifecylce that database modifications are needed. Typical handling for this is:
- Introduce a database version.

There is already (AFAIS) in DBInfo table.

- Newer XnView versions can update from any old database version to the current version. This is performed by applying all version updates one after another that happened between versions.
E.g.
XnView 0.55 has DB version 0.1 and can create a version 0.1 database from scratch.
XnView 0.56 has DB version 0.1 and can create a version 0.1 database from scratch.
XnView 0.60 has DB version 0.2 and can create a version 0.2 database from scratch. In addition, it can update a database from 0.1 to 0.2 (if needed)
XnView 0.61 has DB version 0.2 and can create a version 0.2 database from scratch. In addition, it can update a database from 0.1 to 0.2 (if needed)
XnView 0.80 has DB version 0.3 and can create a version 0.3 database from scratch. In addition, it can update from 0.1 to 0.2 and from 0.2 to 0.3 (if needed).
..

Yes. Usually the create & update things are in fact scripts which are outside of the code base. Sometimes is possible by using CREATE IF NOT EXISTS SQL structures to have a big part of create & update phases together.

But Pierre chose to have these things directly in code. Well, it is his choice. If he can manage them, so far so good (perhaps in a separate class/unit/logical package etc.).

- Older XnView versions will ouput a message if their supported database version is older than the current version.

Well, this is the bit which is missing. A check.