On Tue, 2009-05-19 at 15:57 +0530, Kenneth Gonsalves wrote:
BS - sheer BS. Even the sqlite people would not recommend it for a financial database. Check out recommended uses of sqlite and also omitted SQL features. Or you want the programmer to write zillions of lines of code to enforce foreign key constraints? And btw, this is not a desktop application - it is a server. --
Dear Kenneth, Yes you are right. While we also want this to work on a desktop, we don't want to use a "slight " database back-end which as kenneth rightly points out is far from being useful for finantial applications.
while people might find different uses of the software, then they may as well write the database and the stored procedures in any given db app. those who downloaded our source would notice that the core logic is nothing more than a set of APIs wrapped inside an application published as rpc service. So one can write a web app with tg2 or rooby or can move the back-end to any other db (while we highly recommend postgresql ).
Moreover the types variety of datatypes, the scope for tuning and richness of the stored procedures all make postgresql the choice for GNUKhata. The issue as I see is "how will the end user configure ". as I said and I repeat, 1, the end user need not do that because software takes care (deb and rpm packages due ) 2, deployment is a work which is supposed to be taken care of by admins and experts. And an accounting software being deployed in any medium to large scale office would any ways involve a sysadmin.
3, as far as possible and till the point where it is doable, we have automated the task. For example look at the install.bin in the source folder, it automates the database creation and also puts the factory defaults.
We are writing a bash script which will convert the rpc application into a demon which will start as a service and this script will be put in the deb and rpm to be executed. So the setup procedure will really "set it up ".
I hope this clears out all the doubts.
happy hacking. Krishnakant. ps: Kenneth, thanks for answering those queries when I was not at the desk. You seam to have got the approach we have taken correctly.