access_method and new, empty, sessions.

[Derek Atkins]

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?

> i.e. if session->backend is NULL, the session isn't saved and the user isn't 
> told! (This is G2 and HEAD (and QOF)).

Hmm...  At some level I guess this makes sense.

> The reason we don't see this happening is that qof_session_begin assumes the 
> GnuCash XML v2 file:/ backend if it can't get anything else to initialise by 
> falling back to the file:/ access_method and the first available backend for 
> file:/. (Which is no bad thing).
> :-)

Well, it might complicate things in the case of SQLite, if it's
assuming the database already exists before it will do anything.
However we may be able to still handle that case by the way we plug in
the QofBackend based on whether it's the "default" setting of there's
actually a real instantiated database sitting behind the backend.

In the normal case, when the backend has an instantiated db file,
there's no need for 'save'...  Whereas in the startup/new-file case
you DO need to 'save' in order to specify the db filename.  Ahh,
corner cases..  :)

> (In QOF, it assumes QSF because that's the only file:/ backend).
>
> 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.

>> > If the flag had different values for QSF and SQLite, qof_session_save
>> > could know how to find the _new() routines for the required backend.
>> >
>> > Maybe an enum?
>>
>> No, enums are bad..  Not pluggable.  Use a glist or hash table.
>
> ? When plugged into qof_book_set_data, it *is* a value in a hash table. What 
> would I put into the GList to use that as a value in the book data hash 
> table? Is this for fallback reasons (future-proofing)? We can't let a partial 
> book fallback to a backend designed for a full book.

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.

So, just use file-backend strings.  :)

> Are you saying to g_list_prepend the details of the preferred backend for the 
> book and then the code just takes whatever is first in line? What value 
> should I use? 

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.

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.

> qof_session_load_backend says:
>  /* FIXME: this should use dlopen(), instead of guile/scheme,
>    *    to load the modules.  Right now, this requires the engine to
>    *    link to scheme, which is an obvious architecture flaw.
>    *    XXX this is fixed below, in the non-gnucash version. Cut
>    *    over at some point.
>
> Seeing as the load_backend_library function using dlopen() via 
> QofBackendProvider is the way forward for backends, this could be the 
> provider->name string. Functions that set the flag would need the value of 
> provider->name to be set by a #define in qofsession.h to avoid typos - not a 
> problem.

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.

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

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

[partialbook]
> The only question is what kind of value we want and what it should contain.

I'm not sure it matters; a boolean value is all you really need,
AFAICT.

-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