[Kmymoney-devel] missing subject

[Fernando Vilas]

On Monday, August 11, 2014 07:46:29 PM Christian Dávid wrote:
> Hi Fernando,
> 
> sorry, I received your mail mutilated. This will make this mail hard to read
> and I manipulated some quotes to make it not that worse.
> 

Sorry about that...  an upgrade to my system broke the MIME type parsing and 
broke email for me (for over a month). An upgrade to a recent git (20140920) 
for the KF5 version of KMail seems to have finally fixed it.

> Am Sonntag, 10. August 2014, 18:01:37 schrieb Fernando Vilas:
> > […]
> > 
> > > Now I added a new column to kmmFieldInfo in MyMoneyDbDef::FileInfo(void)
> > > using:
> > > 
> > > appendField(MyMoneyDbIntColumn("hiOnlineJobId", MyMoneyDbIntColumn::BIG,
> > > UNSIGNED, false, false, 8));
> > > 
> > > First question: is that correct?
> > > 
> > > If I open KMyMoney with a sql-database it crashes because it tries to
> > > select
> > > the new column "hiOnlineJobId" (or even tags if the version is 6) before
> > > it
> > > updated the database.
> > > 
> > > I did some investigation and noticed that the upgradeToVx() methods call
> > > readFileInfo() and writeFileInfo() quite often. But these methods use
> > > m_db.m_tables["kmmFileInfo"].selectAllString(). This leads to the
> > > request
> > > for
> > > non-existing columns (-> exception -> crash).
> > 
> > Those methods are intended for a few of the more complex updates to the
> > structure we made in the past. I think just rolling the version number
> > will fix it, but I need to look harder at it.
> 
> No, setting the version correctly still leads to the same issue.
> 
> I even think, this behavior will prevent the upgrades to v1, and v7 as they
> call readFileInfo() and new columns were created in that versions. If you
> have to upgrade more versions than just on (vN -> vM | m >= n+2) it will
> even fail if you start with any version before v7 (= all possible update
> processes).
> 
> Actually the test databases which I just created (using master branch)
> identifies itself as version 6 but it should be v7. This indicates a bug in
> the upgrade process.
> 
> _ Solution _
> 
> I would recommend not to use readFileInfo() and writeFileInfo() in any
> upgrade methods anymore and just call writeFileInfo() at the end of the
> upgrade process. Also the m_hi…Id vars need to be set somewhere.
> 

That sounds reasonable. The system was designed to make upgrades easy, but 
there are always cases you did not consider. I do not remember us considering 
removing columns, just adding/changing them, so this is new territory.

> There was never a version released with database version 7 officially (it
> adds tags). Should I add my changes to version 7 as well?
> 

I think so. They may already be incorporated, given the way that upgrades 
happen. If there is no upgrade function needed, just adding columns/tables/
views, then the program just adds them when the DB connection is opened.

> How is the database created if you create a new database from scratch:
> 1) Is the most recent database version created directly? Or
> 2) do you create a database of version 0 and then call all upgrade methods?
>

It should be option 1: just creating the database using the current state of 
affairs for tables/views. That definitely simplifies things, but can make 
testing the upgrade functions non-trivial.

Thanks,
Fernando