GncBusiness v. GNCSession

Dave Peticolas dave@krondo.com
21 Nov 2001 17:45:08 -0800


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

On Wed, 2001-11-21 at 14:34, Linas Vepstas wrote:
> > and not a book because it seems to me that metadata belongs in
> > sessions, not books.=20
>=20
> I guess I don't understand.  If I have a transaction, and it has=20
> a guid, and I just read it on one session, and am about to write it
> on another session, where does the guid go ??? =20

Well, right now you can't just move transactions from one
session to another, we would need to add some routines to
do that so the entity tables get fixed up. We would need
that regardless of whether the tables are in sessions or
books, unless you are moving the whole book en masse, like
in a save-as operation.


> I am assuming its possible to have one book associated with=20
> two sessions, but maybe this assumption is bad ... ?

No, that's not really possible.


> If I start gnucash for the very first time, and have never saved
> to a file before, and just start entering data, is there
> a session open?  (I thought there wasn't?)  In that case, if=20
> there's no session, where is the entity table?

There is always a session open in gnucash, though not necessarily
connected to a backend, and that has been true since I first started=20
working on gnucash. The code that was originally in src/FileDialog.c
was very careful to maintain a current session at all times, always
creating a new one if the current one was ever destroyed.


> > 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.
>=20
> Ah ha -- so there must be a session object, it just hasn't been=20
> 'opened' yet.  Sounds like a rump to me.
>=20
> > 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.=20
>=20
> yes, right.
>=20
> > Whether it's a session, or book, I don't see the
> > big deal.=20
>=20
> Well, let me play devils advocate: if its no big deal, then why=20
> did we separate session from book?  Surely there is a reason.

Sure, I think it's useful to have a top-level data object that
is the sole data item in a session. It keeps the session api
simple in the face of new top-level data types.


> > 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.
>=20
> To me, sessions are for managing a persistant data store.  A data
> store has to have a URL, a backend, and a mechanism for reporting
> network errors.  Mentally, its a glorified socket.
>=20
> The 'object lookup table' doesn't fit in this paradigm.  Its=20
> an 'index' for the data, and the index needs to travel with the data,=20
> it needs to be tied to the data its indexing.  Its not a property=20
> of the socket or shmat, of the connection to the datastore.
>=20
> Off-topic: in the future, the session would be a good place to
> handle at least some portion of user authentication.  Viz: does this
> user have the authority to connect to this data repository?  And if
> so, then what are the user's credentials?   This fits the 'connection'
> paradigm.

I don't really care where the entity tables go, but if they're
moving to books, then I'd like some help rewriting everything.
That means fixing all of the API and all of the C & scheme code
that now passes session arguments instead of books.

dave


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

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

iD8DBQA7/Fik5effKKCmfpIRAs1yAJ9v75YUeIo/ZKTD1Szr24quU4D5uwCgs16b
KnQewRb1sTJO7VoMVJu51x4=
=gTom
-----END PGP SIGNATURE-----

--=-qWzvpkz9AXM6OafcyoCt--