Hi Ralf:

In message <20201118154402.cvygbqhrgspo7pwb@runtux.com>,
Ralf Schlatterbeck writes:
>On Wed, Nov 18, 2020 at 03:19:16PM +0000, John Rouillard wrote:
>> I am still using the classname Computed, but I think it needs a better
>> name. Maybe: Operator, Agent, Broker (my fave so far), Proxy... 
>> Suggestions?
>
>I'd keep Computed as the base class. Other implementation may chose
>to derive from it.

Well this is a base class like Integer, Number, Date ... I don't
expect them to be subclassed.

The only thing you can really set are new methods. New methods are
added by setattr() on the Computed class rather than subclassing.

>It would be nice to make a derived class that can search, too, like
>your implementation of the number of items: This could map to some SQL
>code and thus be searchable, too. (Maybe this needs two different SQL
>parts, one for search one for display, 

For data where the source of truth lives in roundup (e.g. message
count), it would probably be better implemented via a real property
with a detector/auditor that updates the data.

For data where the source of truth is outside of roundup, we need to
cache data locally for all instances of the class. Otherwise we have
to do expensive computation for say 1,000,000 issues of the
field. Ideally that would never be the only field searched, so the
number of computed fields would be a fraction of the total number of
issues but...

If we cache all 1,000,000 issues, they need to be rescanned and have
their values recalcuated into a sql/anydbm cache on a regular
basis. Alternatively the cache could be maintained by a (rest update)
request from the source of truth. (Another reason writing to a
computed field may be useful.)  Otherwise the search results will be
incomplete at best or wrong at worst.

> I haven't looked too closely yet)

I haven't checked it in yet. I can send you a patch offline if you
like. It doesn't have tests and there is no obvious existing test to
extend.

>Concerning read-only: My guess is that most computed properties will be
>read-only.

That was my expectation as well. The current implementation is only
for read only access, but we could have write use cases.