access_method and new, empty, sessions.

[Neil Williams]

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

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

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

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:
<guid type="account">guidgoeshere</guid>

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

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


-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.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/20050218/0e8f60ef/attachment.bin