saving budgets

[Chris Shoemaker]

On Fri, Dec 24, 2004 at 07:17:24PM +0000, Neil Williams wrote:
> On Friday 24 December 2004 12:12 pm, Chris Shoemaker wrote:
> > The current budget design seems to assume that created budgets will
> > live with the accounts.  (There's no mechanism for saving or
> > retrieving budgets from files.)  This makes sense since a budget seems
> > pretty strictly dependent on the account heirarchy.
> >
> > So, if no one else is working on it, I'm considering trying to store
> > the budget in the same place that the accounts are stored.  (I haven't
> > looked into the details, yet.)  Any comments?
> 
> When my QSF code becomes usable, you'll be able to export any QOF-defined 
> object into XML with or without any combination of other objects. This will 
> allow budgets to be sensibly split from one QofBook and merged back into 
> another QofBook using a system of defaults, conversions and lookups. 

I'm not sure I see the utility of moving a budget from one book to
another, but maybe I'm not imagining all the ways someone might use
QofBooks - maybe something with book closing.

> 
> If you make all the budget objects compatible with QOF, all the GnuCash 
> backends will become available, including the future format of SQLlite / 
> database backend.

I'm not sure what "compatible with QOF" means.  I'm looking at
scheduled transactions as an example.  Are scheduled transactions
compaitible with QOF?  I see how the book is written out to xmlv2 and
I think I see how to make budgets written out just like scheduled
tranactions.  Now, I've only looked at the file backend, so I don't
know about postgres or any other backend.  Would making an xml format
for budgets be obsoleted by QSF?

Specifically, I'm considering writing:
xmlNodePtr gnc_budget_dom_tree_create(GncBudget *b);

similar to:
xmlNodePtr gnc_schedXaction_dom_tree_create(SchedXaction *sx);


> 
> The current XML storage of Account requires an AccountGroup - only entities 
> that are children of the root AccountGroup are written to the current GnuCash 
> file backend. This may not suit your design.

Well, actually, I was thinking a budget's XML storage would be
parallel to accounts, not children of accounts.

> 
> If budgets are not going to be ready for a release version until the Gnome2 
> port is complete,

Huh!? I though g2 was going to BE the next release version.

> you won't need to worry about storage - make all budget 
> objects fully QOF compliant and let QOF deal with the storage.

Did you mean "and let [QSF] deal with ..."?

> 
> I'm reasonably confident that QSF will be ready early next year - it requires 
> libxml2 >= v2.5.2 so it needs to go into the Gnome2 port -  the GnuCash 1.8 
> tree and current CVS HEAD generate errors when asked to work with libxml2 
> code.
> 
> http://code.neil.williamsleesmill.me.uk/qsf.html

Ok, I read this document, and the other 12 chapters.  Wow.  That's
some useful documentation.  Actually, it's almost overwhelming!  :)

Here's a summary of my understanding: qof_book_merge is a mechanism
for combining all the data in two books into one book.  It uses QSF as
a transport mechanism, which provides maps and rulesets.  Maps list
labels for qof data structures.  Rulesets provide conflict resolution.

So, really, this is about more than just QSF.  Using qof_book_merge
would mean make everything some type of qofObject, then write maps and
rulesets for merging each type of object?

You expect that this will be used in the g2 branch, right?  What are
the current plans for integration?  I see your tables at
http://code.neil.williamsleesmill.me.uk/problems.html and
http://code.neil.williamsleesmill.me.uk/improvements.html.  What do we
do about "Not suitable for merge"?

ISTM, if there's consensus that this is destined for g2, it's better
to merge it into g2 early and break things than wait until g2 is
"almost" ready.  What do you think?

-chris