Books, sessions [was: Re: UI independance]

[Linas Vepstas]

On Thu, Feb 13, 2003 at 09:48:45PM -0500, Derek Atkins was heard to remark:
> Matthew Vanecek <mevanecek at yahoo.com> writes:
> > Anyhow, I'd really like to emphasize, I like the ability to have two
> > different files open at once.  If we move to the one-instance-at-a-time,
> > we need to make sure we can have multiple files open concurrently...
> 
> Oh, I wholeheartedly agree.  The engine is moving towards that end.
> The GNCSession was meant to be the first step in that direction, but
> it needs to be taken further.  It's going to require rototilling a
> bunch of code to remove a bunch of globals and assumptions about the
> Session State.
> 
> If nothing else it's going to require passing a GNCSession or a
> GNCBook (or some other object that necessarily points back to one) to
> EVERY function, and getting rid of the gnc_get_current_*() functions.
> It's also going to require similar changes to the event processing
> code.

I'd like to take these old comments as an opportunity to open a discussion
about the correct way to handle accounting periods.  There's (old) code
that will split a book into two, dividing up old and new transactions,
and putting them into separate books.  Now, with the new 'lot scrub', 
it is one step away from handling stocks accounts correctly.

But now the next problem arrises:  
-- do people want to look at several books at the same time?
-- should I store multiple books in one file?
-- if they get stored in multiple files, what is the naming 
   convention?  If people screw with the filenames, gnucash might
   not be able to automatically find  older books.
-- how can people run a multi-year report against several old,
   closed books?  How do reports need to be 'fixed'? How do
   the query routines need to be 'fixed'? 

-- should I put several books in one session, or one session 
   per book?  Maybe it should be one session per file ??

-- The SQL backend does not have this complexity of considerations:
   all books are stored in the same DB, this is reasonable, since
   the SQL 'select' capabilities make this simple.  So the
   session/book correspiondence should work for files backend and 
   sql backend, and that is where the rub is.

Advice, comments ... 

Linas.



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