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
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
