More analysis: Failure to save as postgresql database

[Thomas Baumgart]

On Samstag, 30. Januar 2021 01:48:41 CET Jack wrote:

> On 2021.01.25 19:54, Jack wrote:
> > The first few errors I thought were the problem were all "downstream"  
> > failures caused by a db transaction/commitUnit having become invalid  
> > due to a previous query failure and not calling finish on the query.
> > 
> > I'm now pretty sure the first actual failure happens when writeFile  
> > calls writeOnlineJobs. which calls clearTable on kmmSepaOrders.  The  
> > select on that table fails, because that table is not present in the  
> > database.  It appears that all other tables, except that one and  
> > kmmNationalAccountNumber are correctly created.  Just to confirm  
> > that, if I manually create those two tables (any definition - they  
> > are recreated before being used) then I can successfully save to the  
> > database.
> > 
> > Looking at only the first of those two tables, kmmSepaOrders is  
> > created in setupSepaOnlineTransfer (after being dropped if it  
> > exists.)  That routine is called in setupStoragePlugin, which in turn  
> > is called in  actOnOnlineJobInSQL, which also calls  
> > actOnSepaOnlineTransferObjectInSQL.  actOnOnlineJobInSQL is called in  
> > addOnlineJob, which is called in writeOnlineJobs.  (There are some  
> > other calls of these functions, but I've stuck to those it looks like  
> > should get the table created.)    What I don't really follow, is that  
> > in writeOnlineJobs, kmmSepaOrders is cleared before being dropped and  
> > recreated, and clearing it required selecting and then deleting from  
> > it.
> > 
> > What I don't understand, is why those two tables are not created when  
> > all the other tables are initially created.  I have not yet tracked  
> > that down.  I wonder if it is because those tables are only necessary  
> > under certain circumstances.  However, I'm not sure why (or even if)  
> > I am the first person to get caught by this situation.
> > 
> > Separately, I realized that the bug  
> > (https://bugs.kde.org/show_bug.cgi?id=430163) that led me to this  
> > issue is about something else, and not this particular error.  I'm  
> > wondering if I should create a bug or an issue for this problem.  An  
> > issue might be appropriate if we also want to address adding more  
> > checks for other query functions failing, and not currently getting  
> > caught.
> > 
> > Jack
> Doing the same thin in MariaDB (not yet sure about MySQL) it actually  
> segfaults.  In this case, the "Select count(*) from kmmSepaOrders"  
> fails, and he QT_DEBUG_SQL qDebug output includes d->sqlresult->size()  
> which is not valid for a failed query, and segfaults.   (It also  
> segfaults without the QT_DEBUG_SQL, but I don't have a version compiled  
> that way I can run under gdb to confirm.)
> 
> Is it possible that not creating kmmSepaOrders and  
> kmmNationalAccountNumber is just an oversight because they are  
> relatively recent additions to the program at all?

They are not relatively recent additions. They already existed in 4.8 IIRC and
a look at some git output just confirmed that :)

I had a quick look at the code and it seems to me that these tables are created
upon first usage. But KMyMoney tries to clean them no matter if they exist or not.

Creation of these tables happens in (all in MyMoneyStorageSqlPrivate) setupSepaOnlineTransfer
and setupNationalAccount which are called from setupStoragePlugin. The same applies for
the table kmmIbanBic, which is created in setupIBANBIC.

The setupStoragePlugin is called from actOnPayeeIdentifierObjectInSQL and actOnOnlineJobInSQL.

The former is called from the CRUD routines for PayeeIdentifier (add, modify, remove) whereas
the latter is called from the CRUD routines for OnlineJob.

Since I have objects of these types in my file it could be the reason why I did not encounter
this problem. If you don't use these objects, it seems the tables are never created.

A possible fix would be to add a check if a table exists before clearing its contents in
MyMoneyStorageSqlPrivate::clearTable which is called from writeOnlineJobs in the course
of saving the data. Maybe adding 

  query.finish();

to the end of this routine is all we need, since the query failed. I don't know at this point
and leave it to you to try/test.

-- 

Regards

Thomas Baumgart

https://www.signal.org/       Signal, the better WhatsApp
-------------------------------------------------------------
It does not make sense to hire smart people, and then
have them follow stupid rules. -- Oleg Vishnepolsky on LinkedIn
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 868 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20210130/b2e8b4be/attachment.sig>