close books

[John Ralls]

On Dec 7, 2010, at 9:44 AM, Derek Atkins wrote:

> On Tue, December 7, 2010 12:33 pm, John Ralls wrote:
>> 
>> On Dec 6, 2010, at 8:07 AM, Derek Atkins wrote:
>> 
>>> Robin Chattopadhyay <robinraymn at gmail.com> writes:
>>> 
>>>> 
>>>> At a minimum:
>>>> * Update the database schema (sqlite, postgres, mysql) to add a column
>>>> to
>>>> the transactions table called "closing_entry".
>>>> * Update the XML schema to add an element called "<trn:closing-entry>".
>>> 
>>> This would be a backwards-incompatible change.  The real way to do this
>>> is to use a KVP entry.  Patches welcome (it should be really easy to add
>>> this KVP entry).  See the Transaction Notes APIs for how this can be
>>> done -- although that uses a string, not a boolean, but the concept is
>>> the same.
>>> 
>> 
>> Do we really want to freeze the database schema for ever? Certainly a
>> database change requires as part of the job an upgrade routine so that the
>> current Gnucash can read older versions, but why should we box in future
>> development (or even bug fixes!) by requiring that 2.2.x can read all
>> future databases?
> 
> No, and I wasn't proposing that, either.  We *SHOULD* require that 2.2.x
> can read anything created by 2.4.x.  However that does NOT follow that
> 2.2.x should be able to read 2.6.x.  The idea here is that we could add
> the read routine in 2.4.x so we can recognize the new structures, but
> don't create them until 2.6.x.
> 
>> A KVP *is* better, but because it's better architecture: The closing-entry
>> mark would apply only to one transaction per year, would only be important
>> to one split in that transaction (the income/expense split; one wouldn't
>> want to hide the split from equity reports), and wouldn't have any
>> applicability to any transactions which don't touch income or expense
>> accounts. Something of such limited scope doesn't deserve a column.
>> 
>> Note that the KVP should be on the split, not the transaction, because
>> many income/expense reports don't need to look at the whole transaction,
>> they just need to total up the credits and debits shown in the splits
>> occurring between two dates.
> 
> I still believe that the mark should go into the transaction, not the
> split.  The reports can decide whether or not to include the split(s) in
> their calculations.  And it's very easy to test
> split->parent->isClosingEntry().


Schema: OK. To make the policy clearer, backwards-incompatible schema changes in 2.5 require a change to 2.4 to provide a read facility for the new schema. 


Split vs. Transaction: OK, it looks like it doesn't matter anyway, since the dates live in the transaction, so it has to be joined with the split to filter the report.

Regards,
John Ralls