Recursive QofBooks

[John Ralls]

On Aug 13, 2011, at 12:23 AM, Geert Janssens wrote:

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

No, it does basically the opposite: It makes a copy of a book and all of its accounts, then closes the old book into the new book (transferring income and expense balances to equity and zeroing them, copying over "opening" transactions for open lots, invoices, etc., and whatever other closing things Gnucash does.)

I've removed Periods and all of the unused functions Muslim found while writing his unit tests. The result builds, runs, and passes make check. I've pushed it to https://github.com/jralls/gnucash/commits/Decruftification. If no one objects by Thursday morning (mine, UTC - 7), I'll rebase it onto trunk and commit it to SVN.

Regards,
John Ralls