[Kmymoney-devel] Allow plugins to access the database

[Christian Dávid]

Hi Fernando,

Am 15.02.2014 um 23:44 schrieb Fernando Vilas:
(mail cited incompletely)

> The simple answer is to add the table, as you saw. That addresses the initial 
> concern for getting the data integrated.
> 
> You want the plugins to be able to execute SQL queries directly. That is a 
> little counter to the idea of abstracting the storage layer through the MMFile 
> object. If it has to violate that, it can possibly be addressed, but there may 
> be a way to add features to the storage layer or MMFile to continue the 
> abstraction. 

You are right. But if a plugin wants to store data we must ‘leave’ the abstraction somewhere. There is no way to extend MyMoneyFile to handle that as the plugin alone has the knowledge to store and restore information. There is no way to give that information to MyMoneyFile.

If we want to keep the abstraction even here, we need to use a object-relational mapper layer (e.g. odb [1]). This would be a major change in KMyMoney, which is too huge for me. Also these techniques do not seem to be spread, I guess there is a reason for it (please correct me if I am wrong).

Of course we need to trust the developers to use the direct SQL connection responsibly. That means: do not combine the application logic with the database where it is not needed (see also [2]).

In the future we can rethink if the abstraction through MyMoneyFile is still useful, as we could use SQL directly (and the xml file could be replaced by sqlite). And the current storage system is a bit massive and confusing in my opinion. But this is beyond what I want to solve now.

> 
>> Also the plugin should tell KMyMoney an SQL query which reverts the changes.
>> It is stored as a string (in the database). Then KMyMoney can offer the
>> user to remove all data from a plugin — even if it is no longer available.
>> 
> 
> Interesting. If the idea is to allow reverting commands, maybe the original 
> writes to the database can be delayed until complete. That way, the 
> transaction is still atomic.

This was not meant to allow transactions. An example; the plugin foo creates a table ‘fooPlugin’ to store data. The user removes the plugin. To keep the database clean KMyMoney can inform the user about the missing plugin foo and allows him to remove the data of the Plugin. The stored SQL query would remove the table ‘fooPlugin’ then.

>> Do you like my idea?
> 
> Maybe...  I don't really have enough information to have an opinion yet. You 
> seem motivated on this, which is fantastic.
> 
> Could you share some of the code or more in-depth thoughts on the design? That 
> would help. I do not know if reviewboard is the right place for a work-in-
> progress, but something like that could help me (and others) see a prototype 
> of what you are thinking.

I wanted to ask you first so I do not waste time on futile efforts. If everybody could live with the idea to allow plugins to query the database, I can put more thoughts on it an present some code.

Greetings
Chris

[1] http://www.codesynthesis.com/products/odb/

[2] Alternatively we could create a MyMoneyPlugingObject which has a virtual writeSQL method and a constructor to create from database (like the xml ones) and add a add/modify/removePlugingObject no MyMoneyFile which then call the virtual add/modify/remove method in MyMoneyPluginObject. But then we do not have any chance to use select statements which return more than one object (e.g. for list views). My plugin would use a similar technique for that.