[PEAK] model unit tests and a non-association QueryLink
Phillip J. Eby
pje at telecommunity.com
Wed Nov 10 17:30:03 EST 2004
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.
More information about the PEAK