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? 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. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
