[PATCH 3/9] Re: Experimental LocalStatus stored in SQLite database

[Nicolas Sebrecht]

On Thu, Apr 28, 2011 at 03:56:20PM +0200, Sebastian Spaeth wrote:

> > > +
> > > +	# MIGRATE
> > 
> > I don't think we want such migration plans here. Handling database
> > format here could end with lot of migration code we don't usually care
> > about.
> 
> This is a leftover from the original. I have done away with all
> migration code in the next patch, I think. The reason is that we can
> just recreate the LocalStatus information from scratch if both LOCAL
> and REMOTE are reasonably in sync. So, we can just disregard the old
> plain text status and recreate the new one as if the LocalStatus cache
> were just missing.

No, we can't. As you stated above, it's reasonable only _if_ LOCAL and
REMOTE are not too far.

What comes to my mind is a fun script to generate either plain or SQLite
data from each other. Otherwise, we have to clearly warn about that in
the doc.

> > Say we're at v6.3.3:1 (:1 for the database format release). Then, comes
> > v6.4.0:2 and later v6.5.0:3... Yeah, you got my point: what shoud we do
> > for people going from :1 to :3?  And we will get things worse than that
> > having SQL optionnal at the Account level.
>  
> > Migrate from LocalStatus to LocalStatusSQLite _IS_ a migration like
> > above. A bit particular due to the creation of the database but it's
> > really the same.
> 
> mmh, as I've written above. If both repos are reasonably in sync, we can
> just recreate LocalStatus without any special need for migration. We do
> store a "version" number of the table format, so we can upgrade people
> that are on old versions when we bump it.

We might not be in sync ourself. :-)

I'm talking about the long term. Again, what we have to do for people
going from :1 to :2 is definetly NOT the same operation as going from :1
to :3.

IOW, we need nice migration plans and code to handle the latter case the
right way. What's the most sensible would be a step by step migration:

  1) change data format from :1 to :2
  2) change data format from :2 to :3

By convention, I think we should talk about the current plain format as :0.

> > > +	        line = file.readline().strip()
> > > +	        assert(line == magicline)
> > 
> > I would add a comment here or implement a dummy (no-op) migration
> > process depending on the migration implementation.
> 
> Right

-- 
Nicolas Sebrecht