GnuCash Daily Source Diff

Linas Vepstas linas@linas.org
Thu, 4 Oct 2001 23:20:59 -0500


Hi Dave,

Sounds good.  I just like to panic when I see 'deep' changes like this.


On Thu, Oct 04, 2001 at 02:40:49PM -0700, Dave Peticolas was heard to remark:
> As long as the entity table
> is global, you can't have multiple sessions opening the same
> file, otherwise the second session will overwrite all the
> entries in the global table from the first session.

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 
scenarios that I can think of.. e.g. importing data from outside 
sources, when the newer import overlaps with an older import.  
Alternately, the 'disconnected operation' scenario, when one looses 
then regains a net connection..)

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

OK, yes, that's what I'd want.  I'd hate to have to clone a tree just to
'save as'.

> allows the rpc server to work as
> intended. 

? I can't imagine why/how ...

> Weren't you just calling for the separation of Books and
> Sessions so that there was no longer a 1-to-1 mapping between them?

Yes, but for a different reason: books aka accounting periods are not
the same as sessions.

> What do you see as the role of sessions?

(excuse the following simplisitic language but i wanted to be clear):

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 
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 
multiple writers trashing each other: the session object obtains and 
holds the lock).

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. 

The gnc_engine is built so that opening a session always causes the 
'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 
a 'save' causes the 'cache' to be 'flushed' to the 'file' (or 
flushed to the 'server').    In other words, a standard gnc_engine 
'session' is always associated with the 'local cache' of the data.

And these definitions seem to match what you are building...

===============================================
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 
session, because the guid would already be associated with a session.
(I guess xaccGUIDMalloc() would need to take a session argument ??)

At 'commit transaction' time, you'd have to check for a null guid,
and assign one if one hadn't yet been.  Presumably, at commit time,
you could find the applicable session by tracing up the tree till 
you found something with a session in it ...

Doing it that way would leave the API unchanged.  Not a big deal though,
I guess its half dozen of one and six o the other...

===============================================
Are you planning on checking for & preventing a 'mix up' objects 
beloning to different sessions?  e.g.
s=xaccMallocSplit(session_a); t=xaccMallocTransaction(session_b); 
xaccInsertSplit (t,s);  ?

Is it worth the cpu cycles to do this?

--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
     Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933