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..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
