CVS update: gnucash/src/engine

[Derek Atkins]

linas at linas.org (Linas Vepstas) writes:

> On Thu, Jun 12, 2003 at 12:14:05AM -0400, Derek Atkins was heard to remark:
> > The reason I have for moving the EntityTable is that a GNCBook* has a
> > GUID, and GNC-Events are keyed off the creation/destruction of GUIDs
> > (including Books).  
> 
> Yes that is self-referential.

Yep, and it's a problem.

> > As events use the Entity Table, the Entity Table
> > should last through a session and not be tied to a specific book
> > (since events are also tied to a session, not specifically to a book).
> 
> Huh? In what way?

Well, I was thinking that the Entity Table would just keep
track of all the entities that are active in the current session.
The entity table is currently keeping track of all the objects
cached in the engine (per book).  There is no storage tied to
the entity table -- it's just something to let you know what's
cached.  So I don't see why it's specifically a per-book object.

> > Try running File -> Open Recent and open a different data file.
> > Notice the warning you get about id_type == NULL?  Moving the entity
> > table would fix that..  I think there may be another way to fix it but
> > I haven't looked at it too hard, yet.  I plan to look at it soon.
> 
> My gut impression is to urge the alternative.

Well one alternative is to change all the event code to take a GUID +
Object Type (instead of just a GUID).  The particular problem that I'm
trying to fix is:

        1) you want to know when a book closes, so you register for an event
           for (OBJECT_DETROY, GNC_ID_BOOK)
        2) the book closes and emits an event: (OBJECT_DESTROY, <guid>)
        3) the component manager needs to find the ID for <guid> and
           looks it up the Entity Table.  Unfortunately by this point
           the "default book" is pointing elsewhere, so this "old" book
           isn't in the Entity Table (see referential problem above).
        4) So the component manager complains that it can't find the
           id_type, and can't process the event.

So, one way to fix it is so remove the need to refer to the entity table
from the component manager... And that would require emitting an event
of the form (EventType, GUID, ObjectType) instead of the current
(EventType, GUID).

> Maybe there could be some kind of delegation, where the session could
> ask each book about the entities that book handles?  I don't think I'd
> mind that.
> 
> Just to re-iterate, I really want to keep this paradigm where books
> hold data, while sessions maintain connections ... I fear the change you
> propose, but don't quite grasp the issue ... 

I understand.. There may be other ways of doing it.  I think if I can
stop using the entity table for events then it wont need to be moved.
Although I do think I still want to restructure the Entity Table, more
for speedups than anything else.  Currently a query is pretty much
iterating over every entry in the entity table -- would be much better
if we could iterate over a subset.  No reason to be looking at Splits
when you're searching for Invoices.

> --linas

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available