Dirty entity identification.
warlord at MIT.EDU
Fri Jul 22 10:43:39 EDT 2005
[ 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
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 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
More information about the gnucash-devel