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 <robinra...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
