[Chandler-dev] Recurrence and changes to masters in the dashboard

[Andi Vajda]

On Fri, 26 Jan 2007, Grant Baillie wrote:

> It seems to me that the repository should propagate notifications(*) of 
> inherited values; i.e. if I change x on the master, I should get 
> notifications for each occurrence that doesn't have its own value for x: 
> since effectively those values are changing, too. Note that this is an issue 
> not just for "read", but any attribute that contributes to the display of the 
> summary table.

That could be done indeed, at a sizable perf cost.
How was it done before at the App level when occurrences didn't inherit but 
copy all their values and the master changed later ?

> Essentially, what I'm saying is that the first pass at the 
> "inheritFrom/inheritTo" has the API in a inconsistent state: the repository 
> takes care of getattr() inheritance, which is what we care about in an object 
> model. However, other repository features (e.g.RepositoryView.findValues(), 
> collection reindexing, notifications), are completely unaware. For 
> findValue(s): we have a higher-level, but completely parallel API that does 
> the extra lookups in the case where attributes are inherited. Are there ever 
> cases where you would not want inheritance to be followed?

findValues() is a special case, an optimization, that doesn't do dynamic 
lookup of values, by design. Doing so would defeat its purpose.

Indexes and notifications, if I were to change the code to follow 'inheritTo' 
to notify, would be solved.

The issue with sending notifs about inherited values changing is that I don't 
know that there isn't a local value for the value that changed on the master
until I go check it on each and every occurrence instance already preventing 
that new value from being inherited and making that notif on the occurrence 
bogus. Sending false notifs is pretty bad as well.

I don't know offhand, but doing this 'send a notif to every occurrence if 
there isn't a local value' in a general fashion could be pretty prohibitive... 
The app, on the other hand, has some inside knowledge about which such 
attributes are likely to have or not have such values, maybe ?

It's simple to implement, though, and the perf cost could be mitigated by 
getting rid of dummy occurrence items altogether, keeping only true 
modifications.

Andi..