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

[R. David Murray]

On Tue, 9 Nov 2004, Phillip J. Eby wrote:
> That's correct.  A QueryLink is an implementation thing.  Remember that
> '_load()' and '_new()' deal with the object's implementation; they should
> not be using the client API.  Setting an attribute is client API.

Hmm.  That makes sense.  That presumably means I've been doing my
generated-id handling wrong, and need to rewrite things so that
I'm obtaining the id to store in the database record using oidFor
instead of also storing it in an attribute.

> >Hmm.  Maybe my storage model is flawed?  I mean, how can a QueryLink
> >know that it needs to invaliate its value when the database rows
> >it is based on change, when it isn't being updated by an association?
>
> Correct.

Good.  Glad to know PEAK isn't truly magical (*grin*).

> So there should be a relationship from Account.transactions <->
> Transaction.billedaccount; each should have a 'referencedEnd' pointing to
> the other.

Yes, there is.

> At that point, 'unbilledtransactions' could then be a derived attribute.

Ah, that's the missing piece.  The first time I read over DerivedAttribute
I didn't understand how it worked.  With this additional hint I think
I understand it.

Is there a better way to implement this than just filtering the
transactions list every time the attribute is accessed?  It seems
a little inefficient to load every transaction object for an account
just to get at the last few.  It won't make any appreciable difference
with the amount of data I'm handling, but I'd like to do it right
in case somebody tries to use this system for more data later.

I still feel like I haven't really grasped the PEAK model, but with
every obstacle I overcome I feel like I'm getting closer.  Thanks
for all the help.

--David