GnuCash Daily Source Diff

Dave Peticolas dave@krondo.com
04 Oct 2001 21:48:01 -0700


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

On Thu, 2001-10-04 at 21:20, Linas Vepstas wrote:
>=20
> Hi Dave,
>=20
> Sounds good.  I just like to panic when I see 'deep' changes like this.

Ok, cool. I'm glad I wasn't going down a blind alley :)


> > file, otherwise the second session will overwrite all the
> > entries in the global table from the first session.
>=20
> OK, right.  For a moment, I wondered why you'd want to have multiple
> sessions for the same data in the same process, but I can think of one
> good example (which is merging data from two files, that have
> transactions/acounts in common.  This can occur in at least several=20
> scenarios that I can think of.. e.g. importing data from outside=20
> sources, when the newer import overlaps with an older import. =20
> Alternately, the 'disconnected operation' scenario, when one looses=20
> then regains a net connection..)

My specific scenario is that I'd like to open several connections
to the same sql backend and perform updates, making sure they all
stay consistent, as a way of testing the multi-user sql backend.


> > If you want to do a 'save as', where you discard the old
> > session, then you could just move the book and the entity table from
> > the old session to the new one. I intend to make a session
> > function to support that.
>=20
> OK, yes, that's what I'd want.  I'd hate to have to clone a tree just to
> 'save as'.

Yes, right now the gnc-file.c code does some 'tricks' to make that
work. I'd like to move that into the session code to make it cleaner.


> > allows the rpc server to work as
> > intended.=20
>=20
> ? I can't imagine why/how ...

As I understand the onc rpc stuff, and Derek can correct me
if I'm wrong, it is set up like this:

Client Engine --------\
Client Engine ------\  \
Client Engine ----- Server Engine

So that multple client engines connect to the server engine,
which in turn has a connect to the 'real' datastore. I may
be wrong in this. But if I'm right, the server engine needs
to have multiple sessions open at once.


> (excuse the following simplisitic language but i wanted to be clear):
>=20
> What I'd like to call a 'session' is a 'network connectivity session',
> wherein a user or program gets access to a dataset, does stuff, and=20
> later on finishes up and closes the session.  (In the case of a file
> dataset, a session is the case where that file is locked up to prevent=20
> multiple writers trashing each other: the session object obtains and=20
> holds the lock).
>=20
> By contrast, the book (like an account or transaction) is a piece of
> persistent data, that continues to exist even if there are no active
> sessions connected to it.=20
>=20
> The gnc_engine is built so that opening a session always causes the=20
> 'real data' (that lives in a file or db) to be 'cached' locally,
> in RAM, in the engine.   The GUI manipulates the cache, and then=20
> a 'save' causes the 'cache' to be 'flushed' to the 'file' (or=20
> flushed to the 'server').    In other words, a standard gnc_engine=20
> 'session' is always associated with the 'local cache' of the data.
>=20
> And these definitions seem to match what you are building...

Yes, I think so. When I am finished, every book and its associated
objects will need to be associated with some session, but that needn't
be an 'active' session with a backend hooked up. So that sessions are
the separation between independent data sets.

I intend to implement functionality to 'move' data from one
session to another to implement, say, 'save as'.


> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The other way to implement what you wanted would have been to not set
> any guid at all at malloc time; leave the guid to be zero.  Later,
> when xaccTransSetGUID is called for the first time, you'd know the=20
> session, because the guid would already be associated with a session.
> (I guess xaccGUIDMalloc() would need to take a session argument ??)

Yes, that's the other way to do it. It seemed to me that it would be=20
better to make GUIDs like pointers, and have them be valid all the time,
instead of having them work only sometimes. However, that does require
a few more session arguments.


> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Are you planning on checking for & preventing a 'mix up' objects=20
> beloning to different sessions?  e.g.
> s=3DxaccMallocSplit(session_a); t=3DxaccMallocTransaction(session_b);=20
> xaccInsertSplit (t,s);  ?
>=20
> Is it worth the cpu cycles to do this?

I'm not sure. I was thinking about caching a pointer to the entity
table in the objects to eliminate the need to add session arguments
to a bunch of other functions. This would also make it easy to check
for session mix-up and it wouldn't take very much cpu. In addition, it=20
would also make it easy to 'move' a book/entity table pair to another=20
session without changing lots of pointers. That does add an extra data=20
member to stuff, though. What do you think?

dave


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

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

iD8DBQA7vTuB5effKKCmfpIRAlGrAKC13m75Rz+WBtgvmTS9BgEju4aIjgCgw1Ad
phmHnM8wz4Gbwtx9y89Xml4=
=CrhC
-----END PGP SIGNATURE-----

--=-ePhznT4ID0NyyoJw6zXJ--