More analysis: Failure to save as postgresql database

[Jack]

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?