A couple of suggestions.

[Linas Vepstas]

On Sat, Nov 23, 2002 at 11:17:30AM -0600, Matthew Vanecek was heard to remark:
> On Fri, 2002-11-22 at 20:34, Linas Vepstas wrote:
> > On Fri, Nov 22, 2002 at 09:03:40PM -0500, Derek Atkins was heard to remark:
> > > There are plans to support "accounting periods", so you would only
> > > load the most recent "accounting period", and would have to do something
> > > "special" to see previous periods.  However thank functionality is not
> > > complete.
> > 
> > I'll hapily complete this function if somebody could put me into
> > an income-producing employment situation.  
> > 
> > --linas
> 
> Hm, shoulda spoken sooner.  

Hmm?? I thought I threw up a pretty big hurdle in the "if" clause 
of the above sentance.  Given the (unsurprising) absence of responses, 
its not likely that I'll be whacking at periods any time soon.

> I was going to implement the structure for
> Periods and Budgets in the SQL backend, and work on integrating that
> into the GUI/engine, and provide a path for implementing them in the
> other backends...

Should I presume that you know that there is some preliminary support
for perioods in the engine already?  Its not complete, and there's no
GUI, yet.   What's been done so far:

-- the transactions correspoidning to an accounting period are stored
   in a "book". The engine can work with multiple books at once.  
   Typically, only one book is "open" at a time.

-- There's code in the engine to take an existing book and split it 
   into two books, based on a date (actually, based on a general
   query, which can be a date query), so that the account hierarchy
   is correctly copied, the splits/transactions are moved from one 
   to the other, and kvp's are inserted so that one can find out
   what went where, when, how, etc.

-- Implementing the above made it clear that it is important to 
   implemnent "lots" also, so that stocks could be handled correctly
   accross accounting periods.  More generally, "lots" allow you to 
   handle appreciation/depreciation/cost-basis/net-present-value/etc.
   type calculations correctly across multiple periods.

-- "Lots" are partly implemented.  I needed to implement a FIFO 
   in order to complete the engine work on periods; once that worked,
   it would have been time to add the GUI.

-- there's design notes for this somewhere in the engine.

I mention this, because I'd hate to have you rediscover/revinvent this 
from scratch.    On the other hand, if you already know/understand this,
and agree, then implement away ...


I'd happily do this, if I could get myself into the right frame of mind,
and avoid getting distracted by the 101 other projects I have going.
(such as making "search" work on the gnucash website.. . :-(

> I would like to mention, WRT the original post, that opening a 10M file
> is always a pain, and that this is one of the disadvantages of XML.  My

Yes.
Funny, that.  The gnucash community has consistently stated that an
ascii file format is more important than speed.   I was appaled,
as I was once the victim of being on  the opposite side of this debate:
the VRML crowd (a 3D xml thing) was screaming bloody murder for a binary
file format, and I got badly splattered for rising to the defense
of the ascii format :-(

> little I know of XML), you have to parse the entire XML file at once.

The idea of 'books' was that once you read the entire book, you had
everything you needed to work with that accounting period.

You can store multiple books in one file (I beleive this workls today), 
or I suppose you could store books in sepearate files; no one has written 
the code to do either:

a) read just one book out of a multi-book xml file
b) read mutiple xml files, each containing one book (period).

its not hard, it just requires some thought so that things don't
go bad if the user deletes old files ... 

--linas



-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933