access_method and new, empty, sessions.

[Neil Williams]

On Thursday 17 February 2005 12:40 am, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > Yes, as well as Report->Export data, or any other situation where certain
> > entities from an existing book are to be saved / exported.
>
> Uh, Report->Export exports the HTML results of the report...  I don't think
> QSF applies in that case.

OK, a new option, maybe "export with data". This is one of those add-ons that 
isn't the primary purpose of the code but could solve issues for some users.

Pretty much anything that summarises or reports on the GnuCash data can be 
exported in QSF, with the abiding exception of commodities.

> > At present, qof_session_save doesn't do that, it simply calls whatever
> > backend was selected by qof_session_begin which in turn relies on the
> > access_method.
>
> Oh?  So File -> New File does... what?  There's no backend associated
> with it.  Simiarly File -> Save As, what does that do?

Where no backend is associated, qof_session_save comments say:
  /* If there is a backend, and the backend is reachable
   * (i.e. we can communicate with it), then synchronize with
   * the backend.  If we cannot contact the backend (e.g.
   * because we've gone offline, the network has crashed, etc.)
   * then give the user the option to save to the local disk.
   *
   * hack alert -- FIXME -- XXX the code below no longer
   * does what the words above say.  This needs fixing.
   */

:-(

What it actually does is:

 be = session->backend;
  if (be)
    {
 /* .... use the backend to save */
    }
    /* If we got to here, then the backend saved everything
     * just fine, and we are done. So return. */
    qof_session_clear_error (session);
    LEAVE("Success");
    return;

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

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

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

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

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? 

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.

Current strings in provider->name include a version number - maybe we need 
that separated out into a provider-> setting of it's own?

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

> We definitely need to keep track of whether a book is a 
> Full Book or a Partial Book and act accordingly.

Absolutely.

I'd recommend using a "PartialBook" key in the qof_book_get_data hash table. 
If that is NULL, it's a full book, if it has a value, it is a partial book 
and the value denotes the backend that must be used for that partial book.

We could have a positive setting for FullBook but as none of the existing code 
uses it, all we really need is a reliable way of identifying a partial book 
and let everything else go through to what it has always used.

The only question is what kind of value we want and what it should contain.

>
> -derek

-- 

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/20050217/08e7fd31/attachment.bin