qof_book_get_guid deprecated?

[Neil Williams]

On Friday 31 December 2004 3:24 pm, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
>
> > 2. As QSF supports partial books, (by using references), if a user
> > selects a range of transactions, or a range of accounts including
> > transactions between dates, or all invoices for a customer over x months,
> > etc., this can be passed to the QofBackend via a second QofSession and
> > the data will be written out without the need for any hierarchies or
> > AccountGroups or other components of a full QofBook in GnuCash. (via the
> > clipboard?).
> >
> > Should the QSF file then use the ORIGINAL QofBook for the GUID of the
> > book written into the QSF file? All the objects themselves will retain
> > the same GUID as the original book (which will make it easy to merge the
> > partial book back into the original). The temporary QofBook in the second
> > session will only live as long as the export is in progress but I can use
> > that GUID if that would be better. (i.e. versions, time delays, multiple
> > QSF files with the same book-guid, . . )
> >
> > Is the export an independent book or a derivative?
>
> Good question.  I have no idea.  What are the ramifications of either
> choice.

Not using the book GUID:
Things carry on as now, really. I can't see many places where GnuCash uses the 
book GUID because it's currently all about the one current book. If multiple 
books in the same QofSession are in use, the GUID becomes important. 
Exporting QSF data without the original GUID in this situation could prevent 
the user being warned - although there are situations where this would be 
what the user wanted anyway. :-(

Using the book GUID:
The user can be warned if there is (or is not) a clash, depending on the kind 
of merge in progress. This only matters if the source of the import data uses 
GUID's. If users are able to merge closed fiscal years into the current year 
or even a temporary book (for reporting purposes), it may be wise to check 
the book GUID. Thereagain, if the user selects the wrong file to import, 
there's not a lot more that can be done - the merge is full of warnings about 
not being able to undo the final Commit operation.

Not a lot in it really - unless you can think of other situations.

> If a user imports it, will the merge code notice that the 
> book guid is the same and therefore not import anything?

This wasn't an issue with the hierarchy druid, it could be with QSF so 
currently, qof_book_merge only looks at the object GUID. 

I don't think it's a major issue overall, whether the book GUID is utilised - 
but it could be handy if the user wants to partition several QofBooks into 
separate files and merge them later, or if users have more than one main data 
file/source and want to keep their exported data separate. 

It could also be relevant when QOF is used outside GnuCash.

> Or does the 
> merge code ignore the book guid?

Currently it does ignore the QofBook GUID because the import data is coming 
from a temporary source.

It's as much about future-proofing as anything else. How much does GnuCash use 
the actual book GUID currently? It may be important if multiple books start 
being used within the same QofSession but until then, QofSession itself can 
provide identification of which book to use. 

> > Every QSF import will go via qof_book_merge to provide user intervention
> > and collision handling.
>
> ok.
>
> I wonder -- how does the merge code know whether a GUID should be
> created during the merge vs. when it should use the original GUID?

qof_book_merge only accepts existing QofBooks so by putting the data into a 
second QofBook, any GUID's are already created. The merge code then compares 
the object GUIDs and only sets an object GUID itself if the object is new to 
the target book. This makes it possible to update that object more easily 
next time if the source application also uses GUID's. That's the principle 
behind the use of the book GUID.

> E.g. File -> New File needs to create new GUIDs in the accounts it
> creates.

That's a case in point - examples like that mustn't be allowed to set their 
GUID or we'll have lots of books containing identical objects with identical 
GUIDs - merging those will be bad news!

Overall, I think this has to a choice by those using QSF - it's not something 
I can second-guess. I'll see about adding a function to the API that allows 
the original QofBook GUID to be set, probably by handling the QofSession code 
myself and storing the original GUID in the QSF context. It'll also need a 
complimentary call in qof_book_merge to determine whether a difference or 
clash in the book GUID is important. I'll set a default of false. It's not 
difficult to add, which is just as well.

-- 

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/20041231/e9179ce7/attachment-0001.bin