[Kmymoney-devel] Allow plugins to access the database

Fernando Vilas fvilas at iname.com
Sat Mar 29 02:35:39 UTC 2014


On Thursday, March 06, 2014 13:28:01 Christian Dávid wrote:
[...]
> 
> 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.
> 


I think I understand what you are up to now after this and some of the 
checkins in the onlinebanking branch. In particular, the work on the XML 
backend. Overall it looks like a good idea.

Sorry I have been unable to work on this much lately, but I should be able to 
think more about it soon. If you don't mind, I think I will try to build a set 
of stubs to show an example of how to implement it. You will still have to fill 
in the details, but I think there is a compatible path forward.

> 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.

I really like this idea, with some accessors to return collections as well as 
single items. However, I think this may be a lot of work. It should be 
possible to get the existing plugin to a state you want it, then start 
refactoring to a plugin architecture. Something like the "crawl, walk, run" 
idea.

Great work so far.

-- 
Thanks,
Fernando Vilas
fvilas at iname.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20140328/bebba506/attachment.sig>


More information about the KMyMoney-devel mailing list