Recursive QofBooks

[Geert Janssens]

On zaterdag 13 augustus 2011, John Ralls wrote:
> Along a similar vein, there's src/engine/period.[ch] and the "gemini"
> structure which depends upon it. The idea there appears to be that when
> one closes the books (in the accounting sense) at the end of a period, the
> book (in the Gnucash sense) also gets closed out and a new one is cloned
> from the old one.
> 
> Users periodically ask for that and we tell them that that's not something
> we want to do, because the history gets broken up into several files. (It
> would work better with a proper DB backend like DBI, where the "new" book
> just means a new GUID on records and searches can span multiple books. For
> that matter, there's no reason an XML file couldn't also have several
> QofBooks in it. This could be made to work well with XQuery -- or even
> just XPath -- integrated into the XML backend.)
> 
My first reflex would be to keep this code. I think being able to handle 
separate periods is a useful concept. But thinking a bit deeper, it may not be 
as straightforward as just using a new GUID to declare a new period/book.

A lot of objects are period independent: accounts, owners, tax tables,...

So if you change periods by changing books, you will either loose all these 
objects or have to copy them over. Neither is really desirable.

I can imagine two alternatives that do a better job:
- add a period field to those objects that are period dependent (transactions, 
splits, lots,...) and use that to filter period related information.
- define another container kind of object for periods that would contain all 
period dependent objects per period. Something like
/book
  /accountA
  /accountB
  /vendorA
  /...
  /periodA
    /transA
    /transA'
  /periodB
    /transB
    /transB'

> If we really don't want to do that, we should rip out all of that code so
> that it doesn't have to be included in the "transactional" redesign.
> 
I haven't looked at the code, so I don't know if it would make sense in either 
of the above schemes.

If not, IMHO you can also just rip it out.

Geert