access_method and new, empty, sessions.

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

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

Fair enough.

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

This all looks quite sane to me.  :)

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

That's not the issue here.  The issue is about being able to find the
code at runtime and other linkages.  The business-object XML code
links against the XML File Backend.  Howvever I guess it really
doesn't matter too much; the "backend extension registration" happens
in the engine, so it doesn't really matter how the object is loaded,
just so long as it gets loaded and initialized.

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

I'm less worried about export as I am about import in this case, but
it's the same issue, so, yea, it's not an issue.  Well, except for the
fact that gncmod-business-file depends on gncmod-file-backend.

> OK, I'll leave gnc-backend-file-v2 alone.

Probably the safest at the moment.  Eventually we'll "fix" the
modularization (again?) and then we can re-think how that will all
work.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available