Dirty entity identification.

[Derek Atkins]

Chris Shoemaker <c.shoemaker at cox.net> writes:

>> So the Account can only iterate over all it's splits and the Trans can only 
>> iterate over all it's splits. Neither can identify a single split without 
>> iteration. The hierarchy is not symmetrical neither is does it accord with 
>> the tree model.
>
> I'm not sure it's all that complicated.  I think split cascades to
> account, account cascades to book, and transactions can just cascade
> to book, too.  With a few other things cascading up to book, I think
> David would have what he wants.

What about Customers?  Invoices?  PriceDB Entries?  SXes?  Commodities?

There are lots of objects in the database that can be touched/modified
that don't fall into the CoA tree structure.  Please don't limit
yourself to thinking only about the CoA.

Honestly, I really don't think we don't need to know which objects are
dirty.  I just don't see that as a requirement for anything we're
doing at the moment, or in the future.  Besides, if we wanted to, we
could just create a second HashTable in each Collection and put a
reference to each committed/changed object into that second HashTable.
It means we'd effectively need twice the amount of metadata storage,
but I don't think those hash tables really take up a lot of space.

However, I still don't think we need that at the moment.

-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