Xapian devel - Apr 2007 - Re: [Xapian-commits] 8351: trunk/xapian-core/ trunk/xapian-core/backends/flint/

olly wrote:
> SVN root:       svn://svn.xapian.org/xapian
> Changes by:     olly
> Revision:       8351
> Date:           2007-04-23 01:44:44 +0100 (Mon, 23 Apr 2007)
> 
> Log message (2 lines):
> backends/flint/flint_version.cc: Update the flint format version
> since older flint versions can't read compressed tags.
Am I correct in assuming that this means that when people update to 
version 1.0, they're going to have to rebuild their databases?

Presumably, the newer flint code can still read the earlier databases, 
so should we be trying to make the code backwards compatible - ie, make 
flint in version 1.0 able to open dbs with version number 200611200u?

-- 
Richard

On Mon, Apr 23, 2007 at 08:51:35AM +0100, Richard Boulton
wrote:
> olly wrote:
> >backends/flint/flint_version.cc: Update the flint format version
> >since older flint versions can't read compressed tags.
> 
> Am I correct in assuming that this means that when people update to 
> version 1.0, they're going to have to rebuild their databases?
That was already the case, due to the change in 200611200 which fixed
the architecture dependent positionlist encoding.  Sadly that was
unavoidable since databases are supposed to be portable between
architectures (and apart from this bug, they are).
> Presumably, the newer flint code can still read the earlier databases, 
> so should we be trying to make the code backwards compatible - ie, make 
> flint in version 1.0 able to open dbs with version number 200611200u?
I actually started writing such code, but then realised it only benefits
people who are using SVN - those using 0.9 will have to rebuild anyway.

If you are using SVN and have 200611200 format databases, you can
"upgrade" them simply by copying over an "iamflint" file
from 200704230
format database.  But that trick won't work for a 200506110 format flint
database (as used by 0.9.2-0.9.10), unless the position list table is
empty.

It would be possible to write an updater for 200506110 format, but if we
do that we can trivially get it to update 200611200 too.

Cheers,
    Olly