[PEAK] model unit tests and a non-association QueryLink

[Phillip J. Eby]

At 12:17 AM 11/10/04 -0500, R. David Murray wrote:
>On Tue, 9 Nov 2004, Phillip J. Eby wrote:
> > Yes, use a QueryLink referencing a QueryDM.  One way to do this "cheaply"
> > is to make your existing transaction-list QueryDM take a key that's an
> > '(id,unbilled_only)' tuple, that it then uses when querying the SQL
> > backend.  Then, the account state ends up with two query links, one to the
> > full transaction list, the other to the unbilled ones.  Only the ones you
> > actually use will be loaded.
>
>This is cheaper just because I don't have to write/instantiate two different
>QueryDMs?  But now I'm afraid I'm back to not understanding how the QueryLink
>(called from the derived feature's get method?) knows when to recompute
>its list.  I think I'm more confused now (*frown*).

Well, you'll need to get unconfused enough to ask a clearer question, 
because I'm not sure that you actually asked me anything above.  :)

If it's any consolation, the planned do-over of model and storage won't be 
nearly as confusing in these areas.  So much of the complexity in the 
current system is a direct result of ZODB-style "ghosts" and lazy 
loading.  ZODB was intended to work with "oblivious" objects, so ghosts are 
the only reasonable strategy for lazy loading.  However, PEAK is only doing 
persistence with its own "special" objects, so we can afford to (and 
should, and will) give up the "oblivious" support to simplify coding of 
persistence mechanisms.  In the future, objects will not be lazily loaded, 
only *attributes*.  This difference will make things a lot simpler.

Alas, that won't be happening soon enough for your current project, I'm 
afraid.  I'm getting a lot closer to finishing the necessary generic 
function infrastructure, but there's a lot that will have to be built on 
top of it.