GncBusiness v. GNCSession

Dave Peticolas dave@krondo.com
21 Nov 2001 02:35:24 -0800


--=-rx3fMbEgpzJb4Ldxa8om
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2001-11-21 at 02:08, Linas Vepstas wrote:
> > Can you?  It certainly doesn't look that way to me.  All the GUID
> > tables are stored within a session.  Without a session, you have no
> > GUID tables, which means you cannot create any objects.  So I
> > disbelieve that Gnucash works without a session.
>=20
> Ugh.  After a long discussion with dave, he put the guid tables in the
> session, rather than making them global, because this allowed a copy
> operation.   I don't quite remember why he picked session instead of
> book.  Again, something to do with the copy operation.
>
> Dave?  Can you remember why?  Can I get you to add something to the docs
> that says 'the reason that entity tables are in session not book is
> because xyz ...'

Above you say both 'rather than global' and 'session not book'.
The table isn't global so you can have more than one session
open at once, which I believe works right now. It's in a session
and not a book because it seems to me that metadata belongs in
sessions, not books. It could possibly be moved to books, but I
haven't thought it through. Note you don't need an *open* session
to create objects, in the sense that it needs to be connected to
a backend.

I don't quite see the big deal here, though. We need an extra
argument to all the creation functions in order to avoid a global
data structure. Whether it's a session, or book, I don't see the
big deal. Since you can't save or load anything without a session,
you're going to have to create one no matter what.


> Ugh. Since a book serves as the anchor for the account heirarchy, the
> table of prices, etc, you can't create/add/delete data without an open
> book.  To manipulate data, you have to have a book.
>=20
> Unless someone pulled another fast one on me that I don't understand.
> This is what I mean: I don't think we've ever clearly articulated what
> the difference between book and session is, what the correct way for
> using them is, etc.  This is a documentation/architecture problem.
> It should really really be fixed.

To me, sessions are for metadata, like the url where the data
resides, backend connections and object lookup tables. Books
are for actual data that gets stored and loaded.


> > Besides, when the next person comes along and wants to add yet another
> > core object, what are they supposed to do?  A real core-object extensio=
n
> > method would be best, IMHO.
>=20
> You are assuming that you now know enough about what core objects are
> like to be able to make the correct abstraction.  I am not so sure.
> So far, the engine has two core objects: the account tree, and the
> price table.  They are quite different.  Looking at them, I cannot
> really deduce a pattern. =20

Now it also has the list of scheduled transactions.
And eventually the budget data if Joshua's plan
continues.

dave


--=-rx3fMbEgpzJb4Ldxa8om
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA7+4Ns5effKKCmfpIRAt7oAKDnRvNe/6kOF21gWOaNOSdUiqshDACgyv2W
Z1HRj2H9S3wFupBjV2Lr6mU=
=ZkL4
-----END PGP SIGNATURE-----

--=-rx3fMbEgpzJb4Ldxa8om--