Books, sessions [was: Re: UI independance]

[Derek Atkins]

linas at linas.org (Linas Vepstas) writes:

> 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?

Yes.

A better question is, what does this mean?  Personally, I'd like to
_at least_ be able to have multiple files open (in different windows),
sort of like how I can have multiple buffers in Emacs, or multiple
files open in OpenOffice.

Similarly, I think that people MIGHT want to be able to run reports
across multiple accounting periods, so it should be reasonable to do
so (whatever that means).  The benefit of storing accounting periods
in _different_ files is that when you don't want to run cross-period
reports then you don't need to import the old data.

> -- should I store multiple books in one file?

See above about limiting file size..  I don't have a strong
preference.  However, a big part of me would really like to relegate
XML to an interchange format and not a data storage format..  So
trying to optimize for XML might not be a good idea, but YMMV.

> -- 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'? 

The query routines can already run against multiple GNCBook*
objects...

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

That's a very interesting question.  Currently there is a 1:1
relationship of GNCSession* <-> GNCBook*; if we plan to change that
then a lot of other assumptions will have to change.  Note that I'm
not arguing either way, I'm just pointing out an issue with changing
it.  Personally I think a GNCSession should be tied to a file/db/etc.
and GNCBook tied to an accounting period within that file/db/etc.

> -- 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.

Well, if we decide to relegate the file backend to a secondary storage
then the rub doesn't matter ;)

But this brings up an interesting terminology issue.  By "book" do you
mean "Set of Accounts" or do you mean "accounting periods"?  When you
say "all books are stored in the same DB" do you mean that
e.g. multiple companies would use the same DB, or that each company
would have its own DB and just store all the accounting periods in
that DB?  I _think_ you mean the latter, but we should probably choose
the terminology that makes this distinction clear.

> Advice, comments ... 

My advice is that we should optimize for SQL (either the Postgres or
the to-be-written embedded-MySQL Backends) and relegate the XML "File
Backend" to secondary (interchange) status -- then you don't have to
worry about all the issues that using XML files implies.

> Linas.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available