QSF progress.

[Neil Williams]

On Saturday 08 January 2005 1:55 pm, Derek Atkins wrote:
> > Writing a QSF file from a QofBook was made very simple by only requiring
> > one set of handlers. Book, object, parameters - 3 callbacks, 3 foreach
> > loops and it was done. I'd love to see the same with GnuCash and SQLite -
> > to me, it's the only way to have truly portable GnuCash data - it should
> > all be definable through QofObject and QofClass.
>
> Except I don't care about any other application reading the SQLite
> database.  Also, it would mean we can't add stored procedures or use
> any special indexing tricks in the database if we have to abstract it
> through QOF.  I'm thinking of the SQLite Backend in the same way that
> gnucash thinks about the Postgres Backend.

OK.

>
> > To determine the file type for all with one function? Yes. I don't know
> > the SQLite file format but the schema validation will separate QSF from
> > all other file formats.
>
> Yes, that's what I was hoping for -- a single function that could
> detect the actual file type and handle it accordingly.

No problem.

>
> > SchedXaction.c doesn't define any QOF objects although the main struct
> > does use QofInstance so currently, scheduled transactions are not
> > supported by the merge code or QSF.
>
> So what happens if you try to merge a QofBook that has an SX?

Like any other object that isn't currently accessible by QOF, it is untouched. 
If the target book has SX, it is not altered, if the import book has SX, they 
are not merged.

If the definitions are added, I see no reason why they would not merge 
successfully. The same for commodity and pricedb etc. I've added support for 
the business objects and it's all part of the testing. I've got to get this 
sub-account problem sorted and then I can test with other objects.

The currency is only set because of the handler in druid-merge.c - left as a 
plain qof_book_merge, imported objects cannot have a commodity defined as no 
commodities are yet accessible to QOF.

> > In order for a QofBook object to be accessed by either the merge code or
> > QSF, the QofObject definition must have a create: and a foreach:
> > definition and the QofClass parameters must include sufficient parameters
> > to create a fully functioning object with only QofAccessFunc and
> > QofSetterFunc. I'll look at that once I've got existing objects working
> > fully - i.e. fixed this problem that shows up in
> > xaccGroupGetNumSubAccounts.
>
> Well, this GroupGetNumSubAccounts problem could be occuring due to
> SXes being improperly attached to the CoA AccountGroup instead of the
> SX AccountGroup.

No, there are no SX's involved in the merge code - the merge only uses QOF 
objects as described. Plus the example books that I'm using for testing do 
not contain SX's (either in the import or target books) - I test the GnuCash 
merge druid code using the example account trees.

>
> -derek

-- 

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/20050108/96c08c2b/attachment.bin