Suggestions

[John Ralls]

On Dec 3, 2010, at 6:48 AM, ALbert Gráfica - Suporte wrote:

> Hello, everyone, I have some suggestions to the project:
> 
> I pursued the project, so maybe some things that suggest to you that they develop the project to be absurd or impracticable, but they are only suggestions, anyway I'm not a programmer.
> 
> First, GnuCash, the ram carries all data, so in some situations it made the program extremely slow loading or unbearable.
> 
> Well I'm not sure what the purpose of the developers, but if for medium and large enterprise, I suggest you do not load all data in memory (change by period, month), to open around 50,000 trasações, it takes around 5 minutes to 15 minutes (When everything is fine, usuarly 25 minutes). Well that is the 50,000 transactions a month working for some companies.
> 
> Referring to the database, especially when postgres instead of using the DBI driver, why not directly use the functions in postgres, causing them to call from within GnuCash (Or create a file for calls), do not understand why the data need to be loaded into ram and that is a database.
> 
> Multiple users, usually in a company if you need simultaneous access to the database, I read that implementation will not occur or is in version 2.4.
> 
> Well as I said at the beginning am not a programmer, much less understand the development of GnuCash. But I would make these suggestions.
> 

Gabriel,

You're right that loading everything into memory is not the right way to use a database backend and isn't suitable for very large datasets. Worse, the data handling framework that gnucash uses is very xml-centric and forces the sql backend to query inefficiently. Correcting this will require major redesign of gnucash... and we haven't even begun to discuss it. Working with everything in memory is also what prevents multiple simultaneous access, so that won't be possible in 2.4.

Regards,
John Ralls