saving budgets

[Neil Williams]

On Friday 24 December 2004 5:40 pm, Chris Shoemaker wrote:
> > 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.

What about when someone wants to merge a QofBook that contains budgets into a 
QofBook that doesn't? What about when both books contain budgets? Not 
necessarily looking at merging budget per se but handling a merge when 
budgets exist, in either book. qof_book_merge is only going to be able to 
merge objects that are defined as QOF objects.

Budgets (to me) consist of a target spend/income for individual accounts 
summed into an overall +/- in comparison with the real balances. If the 
individual accounts are merged into a target book, shouldn't the budget for 
that account in the import book become part of the budgets of the target 
book? qof_book_merge will deal with collisions, but if both the target and 
import books contain budgets, isn't it reasonable for the user to expect any 
new accounts created from the merge to retain the budgets set for those 
accounts in the import book? Everything else about that account will be as in 
the import book, transactions will also be merged, why not the budget for 
that individual account?

Similarly, if the target book doesn't have any budgets set but the import book 
does, the merge should be able to create everything necessary to make the 
incoming budgets (for the accounts that are in the import book) usable.

This can only happen if suitable QofClass param[] definitions exist.

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

A QofObject definition and a QofClass definition plus utilising the GUID 
internally. It would need to be possible to create a complete budget entity 
from the create: of QofObject and the params[] of QofClass.

Specifically, for qof_book_merge, objects must:
1. Have a create: function for new objects and a foreach: function
2. The object must use GUID internally so that once created, qof_book_merge 
can set the GUID - just like it would be from any QofBackend - so that new 
entities retain the GUID from the import data.
3. Have a complete list of QofAccessFunc and QofSetterFunc pairs in the 
QofClass parameters, sufficient to create a fully functional object using 
only the QofSetterFunc operations and create:.
4. Not have any QofSetterFunc defined if that parameter must not be set 
explicitly (e.g. an Account balance is the sum of the Transactions, not a 
value that can be set directly in the Account entity.) These parameters must 
only be defined with a QofAccessFunc, if defined at all. i.e. the 
QofAccessFunc and QofSetterFunc pairs should be logically intact.

> I'm looking at 
> scheduled transactions as an example.  Are scheduled transactions
> compaitible with QOF?

Look at engine/Account.c, engine/Transaction.c and 
business/business-core/gncInvoice.c instead.

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

No, as Derek says, QSF is about expressing QOF objects between applications - 
allowing data interchange. It is NOT intended as any kind of long term 
storage within GnuCash. It can be used for smaller applications (pilot-link 
for example) as a form of offline storage, but this is not suitable for 
GnuCash.

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

No, I did mean QOF - the replacement for the XML v2 file backend is envisaged 
as SQLlite or a SQL database. All QOF objects will use long term storage 
using this backend - via QofBackend. QSF isn't for long term storage with 
GnuCash.

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

The ruleset is actually part of qof_book_merge - it's generated dynamically 
for each merge operation. I'll try to make that clearer in the docs. The 
merge code can (and is) used independently of QSF. The File->New Account 
Hierarchy merge druid is the current implementation of qof_book_merge in CVS 
and operates without QSF (which isn't in CVS HEAD yet).

QSF uses the maps and defines calculations that can convert between different 
sets of QOF objects - different QOF applications.

qof_book_merge encompasses QSF but can also exist without QSF - it is 
available to anything that has two QofBook's and needs just one.

QSF always creates a second QofBook and therefore always involves a 
qof_book_merge operation.

> Maps list 
> labels for qof data structures.  Rulesets provide conflict resolution.

Yes.

Maps -> QSF (to convert, say, pilot-link QOF objects into GnuCash QOF objects)
rulesets -> qof_book_merge

Maps are not needed if the data comes from within the same application.

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

qof_book_merge cannot deal with objects in either QofBook that are not fully 
QOF compliant. Those in the target book will be ignored, those in the import 
book will not be imported.

As with current structs like gncCommodity, bespoke routines will be needed to 
write non-QOF-compatible structs to the new backend. For as long as these are 
implemented, the structs concerned will remain outside the scope of a 
qof_book_merge.

>
> 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"?

Not suitable for merge means that the value concerned should not be set by a 
merge anyway, it doesn't need to anything done. It's either pre-defined or a 
calculated value.

The remaining issues are mainly down to commodity and prices. If these aren't 
re-written, they'll need bespoke routines to use the new backend(s) and will 
remain outside the scope of a 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?

QSF is not ready for itself yet! QSF only requires g2 in respect of libxml2 >= 
2.5.2 which is not part of the target for the 1.8 tree. QSF uses Schema 
validation of all QSF XML. Plus, QSF doesn't yet support all QOF data types 
or all QSF calculation sets, nor does it yet have routines to create the QSF 
output dynamically.

qof_book_merge is already available to g2.

-- 

Neil Williams
=============
http://www.dclug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20041226/fae88d15/attachment.bin