On Fri, 24 Dec 1999 16:37:49 GMT, the world broke into rejoicing as
Grant Likely <[EMAIL PROTECTED]> said:
> Rob Walker wrote:
> >
> > is it possible to disable the date range in the register display? I
> > would like to see all of my transactions. Especially since I am going
> > to be working on the date field, I would like to be able to just say,
> > "show them all".
> >
>
> Allow me to second that preference.
>
> However, I've noticed that if I set the date range to show all my
> transactions (about 6 months worth), the register slows down
> completely. Is there any way to modify the display so that it only
> loads the transactions from the engine that it actually need to display?
Methinks this goes along with two rather massive changes to the
engine:
a) Providing the ability to write data out to random-access data
structures (I'm thinking of prototyping something where each
transaction establishes its own directory, and then writes data
into a DBM file inside that directory), and then
b) Having some secondary index based on account+date, which allows the
system to jump straight to a particular date. That leaves a
"balance consistency" problem unless we have...
c) A function that takes a start date and an account, and walks through
the account from 0000/00/00 to the start date, and computes the total
up to that date.
In an SQL database, one might do this via something like
select sum(value) from data_table
where account='This Account' and
eff_date < '1999/11/15';
and use the result as the opening balance. If using a Berkeley DB
data structure, this would be more directly expressed as some C
code, and be a bit less descriptive. Not obvious that it would
necessarily be any slower, so long as the value gets cached somewhere,
and the calculation algorithm is reasonably good.
d) The other thing that would logically go along with this would be to have
some sort of "transaction lock" scheme which would forbid two windows
from modifying the same transaction at the same time. The "Mark I"
implementation would involve either:
i) Putting a .lock file in the directory described in a), or
ii) Having a lock table and a lock manager process...
e) The next step, once all of this is done, would be for the only
transactions that are loaded in are those that are actually being
displayed.
This would mandate setting up a "partial balance" table, where
there would be a vector that would contain an element representing
the balance after each transaction. That actually might be a good
thing to implement as part of c)...
--
Rules of the Evil Overlord #15. "I will make it clear that I do know
the meaning of the word "mercy"; I simply choose not show them any."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
