access_method and new, empty, sessions.
linux at codehelp.co.uk
Fri Feb 18 14:55:52 EST 2005
On Friday 18 February 2005 4:59 pm, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > Pretty much anything that summarises or reports on the GnuCash data can
> > be exported in QSF, with the abiding exception of commodities.
> Why not commodities?
Until commodities can be found by QOF, they can't be found by QSF.
I need a foreach function, a create function and a usable QofObject.
It's on my todo list to look at later.
> > I'd add some code here to distinguish full from partial books by reading
> > the book data hash table and inspecting the value for the "Partial" key.
> This all sounds reasonable to me.
That's done. It adds a "PartialQofBook" key with a (gboolean*)TRUE value to
the book data hash table. qof_session_save then inspects the book data and
> Right, but you can't create an enumeration because you do not
> necessarily know all the potential backends ahead of time. In other
> words, you cannot enumerate all the potential objects.
I've realised that QofBackendProvider does that anyway, via it's GSList.
> So, just use file-backend strings. :)
Instead, I've added to QofBackendProvider so that it has a parameter for
"partial_books_supported" which is another gboolean. If that is true, that
backend is considered for use as the replacement for a book that is itself
marked as partial, as above. If the access_method matches, that backend is
used. If no backend matches the access_method, I fallback to file and
Each backend that is added through QofBackendProvider can then do the same.
It's not definite though yet, I'm still experimenting.
As the existing gnc-backend can't support partial books, that can stay as it
is - it gets the default place and only gets replaced if the book is marked
A summary of the API for partial books, so far.
1. A full book must not be marked as partial - create a new one.
2. Partial books contain only COPIES of existing entities.
3. A partial book must not be changed to show as full.
4. Data is only recoverable from a partial book by using a merge. (either
directly or after a save, a merge will still be mandatory.)
5. Copied entities are absolute copies, including the GUID.
(Which kind of explains the first four rules.)
6. Every backend that supports partial books must implement a way of storing
and retrieving entity references.
That last one is where the object contains, e.g. GNC_ID_ACCOUNT as well as the
usual QOF_TYPE_STRING etc. parameters. That complex type may or may not
appear in the partial book and therefore the GUID and type of that reference
must be stored to allow the reference to be re-created when the data is
merged back into a full book.
In the case of QSF, I store that during processing as a hash table in the book
data and write it out into the XML as:
qof_book_merge will be adapted to look for this data, lookup the correct
entity - it is already able to set the reference.
> No, I was saying that the set of backends can be registered in a
> hashtable or glist. How you choose the "preferred" backend I haven't
> considered, yet.
OK, the list of backends provided through the QofBackendProvider mechanism is
a GSList - that's already in place. Registering a new backend is simple but
not as clear as registering a QOF object (although might be improvable
> You're also welcome to extend the QofBackend API to add a "new()", but
> i dont think you really need that; save() should be sufficient. Or
> perhaps I misunderstand what you mean by "new" in this context.
I've added QofBackendProvider pointer and a partial book boolean, that's all,
so far. I may have to add the access_method so that this can be used to pick
the best backend from the list of those supporting partial books (at present,
it's a list with only QSF so that's not hard!)
> Well, it could be a problem; the business-core-file module loads
> through scheme.. So that would somehow need to get loaded properly
> and get all the deps loaded as well.
But the business core wouldn't be copying the entities to another session? The
partial book only matters when entities are copied from one book to another
in piecemeal fashion. When business objects are exported, that can be done
using the qof_entity_copy routines that will set the flag automatically. This
would all be done in the QofBook and the QofSession, it doesn't have to be
done inside any of the existing modules. It just needs a command on the menu
and simple calls to create a new session, copy the selected entities and save
the session. All the hard work is done in qofsession.c and the QSF backend.
All the module loads and dependencies loading are done by the rest of the
program before the export option becomes available from the main menu.
> > Current strings in provider->name include a version number - maybe we
> > need that separated out into a provider-> setting of it's own?
> I dont know.
I'm unsure too - at present, I'm leaving provider_name as an arbitrary string.
> > BTW. We'll need the existing GnuCash XML v2 code for some time after the
> > move to SQLite to cope with archived books, so do you want me to look at
> > converting the current file backend to dlopen()? (Once the QSF stuff is
> > complete.)
> I dont know -- see above about how the business code plugs into the
> existing file backend.
OK, I'll leave gnc-backend-file-v2 alone.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050218/0e8f60ef/attachment.bin
More information about the gnucash-devel