Dirty entity identification.

[Derek Atkins]

[ please trim replies.  these messages are getting pretty long.  thanks ]

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

> Nope.  Accounts contain a list of Splits.  This is an essential part
> of an Account, and *something* needs to know about it and take
> advantage of it.  Other than the GUI.

The Account Object Definition takes care of it.  The implementation
of the Account Object does it.

>> Unfortunately not. The engine cannot know that a dirty "account" (whatever 
>> that is) means a dirty Split (whatever that might be) exists somewhere. There 
>> is no relationship. The engine only knows that this instance is dirty, that 
>> collection is dirty and therefore the book is dirty. End.
>
> You missed the point here.  Forget about the engine.  This was a
> *mathematical* statement about searches.  Having information about the
> presence (or absence) of what you're searching for in a subset of all
> the places you could look at a cost less than the cost of actually
> looking in all those places makes your search cheaper.  This has
> nothing to do with everything that the "engine cannot know."

True, but caching this information (which is effectively what you're
doing) comes at a cost.  You need to store extra data somewhere
(increase storage cost) in order to reduce (time) cost of a search.
All well and good, provided you know a priori which searches you need
to optimize.

QOF is a general search engine and really does NOT understand some of
the optimizations that can be made.  For example, we actually lost a
particular optimization in the move from a "Search Accounts for
Splits/Transactions" to QOF: we lost the ability to reduce the
search-time by limiting the search to only Splits in particular
Accounts.  This lossage happened necessarily because QOF does not
understand that Accounts contain Splits.

_Accounts_ know that Accounts contain Splits, but QOF does not...  And
it's QOF that performs that search.

Now, if QOF were extended in such a way that these relationships could
be declared, it may be possible to regain that opimization.  Maybe.

>> You continue to assert that the engine can follow a path that simply does not 
>> exist. There is no tree!
>
> No.  I made no assertion about *who* can follow that path.  But the
> path does and must exist and we use it already to accomplish most of
> the financial operations.

And see, that is exactly the issue.  There's an abstraction barrier
which you want to cross.  :)  Yes, the information does exist, but
it's not available at all levels.

-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