access_method and new, empty, sessions.

[Neil Williams]

On Wednesday 16 February 2005 9:30 pm, Derek Atkins wrote:
> > I'm now trying to see how it can work when qof_session_new() and
> > qof_session_begin() are called where no content exists, i.e. new, empty,
> > sessions.
>
> You mean what to do when we use File -> Save As?

Yes, as well as Report->Export data, or any other situation where certain 
entities from an existing book are to be saved / exported.

If, e.g. the user runs a report, that in turn may run certain queries and 
other rules to select the entities to build into the report data. Using the 
copy routines, all the entities behind the report could be put into a second 
session and saved to QSF as an "export the report data" command. More than 
just saving the presentation of the report, this would export the data set 
behind the report - allowing data mining and customised report layouts using 
external tools.

e.g. it should be possible to build a simple parser for QSF XML (in Perl, PHP, 
whatever) that could reformat the data into bespoke invoices and other 
customised layouts that are just too individual to warrant a report of their 
own.

> I think in general 
> from the user standpoint it's fairly "obvious" what they want.  The
> user is never going to "File -> Save As" QSF, it's always going to
> save as the "primary" file:// method.

It's tied in with those qof_entity_copy routines - a regular GnuCash book 
can't save a QofBook that doesn't follow the AccountGroup hierarchy, so if 
this isn't a complete file, just a selection of entities, the user should 
expect that a suitable format is used.

> > Is the access_method more of an identifier than a reflection of a
> > protocol?
>
> If I'm understanding what you're asking, yes.  We're not using IANA
> protocol definitions in the discriminator.  The "protocol" field is
> just a tool to allow the user to differentiate between different
> access methods.  Generally they have two choices now, file:// or
> postgres://

OK.

> > How should I proceed to discriminate two backends that use the same
> > access_method when no content exists yet?
>
> Do you necessarily need to choose up front?

Come to think of it, probably not. After all, until the data needs to be 
saved, it's just another QofBook. 

When we need to save and decide which backend to use, we still need a way to 
load a specific backend from amongst the file:// access_methods.

I can use qof_session_destroy_backend(session), then initialise a known 
backend directly using qof_book_set_backend() - it's about how to pick one 
from many file:/ backends.

I'd rather that each of the qof_entity_copy functions (and anything else) that 
create partial books are not forever tied to a specific backend.

I'd prefer a general usage function in qof_session.c that allows a different 
way of selecting amongst the existing file:/ backends - bearing in mind the 
two systems too, gnc_mod and load_library.

> Where are the cases when 
> this is an issue?  AFAICT it's only an "issue" during File -> New File
> or when you run (effectively) gnucash --nofile.  At that point the
> user clicking on "save" is effectively calling Save As.

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.

How would qof_session_save determine the nature of the contents of the 
QofBook? (without converting the entire book to each format in turn so that 
the existing file_type routines could be used!)

What about if the qof_entity_copy routines put a flag in qof_book_set_data() 
that can also be set by any other routines that will result in partial books?

save could then use that to destroy the old backend, create a new one and 
execute the save?

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?

typedef enum partial_book {
 GnuCash = 0,
 QSF,
 SQLite
};

?

qof_book_set_data(book, "partial_status", partial_book);

?

Maybe the results of partial_book in a switch could call a specific backend 
using prov->description?
switch (partial_book) {
 case QSF : 
 if(0 == safe_strcmp("QSF Backend Version 0.1", prov->description)) {
  if (NULL == prov->backend_new) continue;
 }
 break;

(the default would be gnc-backend-v2)


> > Should I use and support:
> > session = qof_session_new();
> > qof_session_begin(session, "qsf:/somefile.xml", TRUE, FALSE);
> >
> > using an arbitrary qsf:/ access_method?
>
> If you want.  Do you need to do so?

Only if changing the backend would cause problems for a live book - after data 
had been added or modified.

Can you see any problems with changing the backend of a book in use?

> > (Loading an existing file that contains QSF data using file:// will still
> > load it as a QSF file.)
> >
> > Is there an alternative method?
>
> I don't know, I haven't looked at that code extensively.  But keep in
> mind that it's going to get much more complex once we add SQLite to
> the mix.

OK, that'll be file:// too, so that would use the same system - if we choose 
to use a flag in the book data that is set by any routines that require a 
certain file backend?

Make it part of the API - if you create a QofBook that cannot or should not be 
saved by the default GnuCash-xml-v2 file backend, specify the type of backend 
in the book data . . . 

-- 

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/20050216/227b8139/attachment.bin