Ticket #510 (closed Enhancement: fixed)
modification date should bubble up to parents/composites
Reported by: | Malte | Owned by: | jri |
---|---|---|---|
Priority: | Major | Milestone: | Release 4.4.1 |
Component: | DeepaMehta Standard Distribution | Version: | |
Keywords: | Cc: | dgf | |
Complexity: | 3 | Area: | Application Framework / API |
Module: | deepamehta-core |
Description
... when an aggregated/composed ChildTopic? is modified, the parents modification date should also be updated.
At the moment a plugin devloper has to do this manually and this may lead to unwanted presentations, (since the new HTTP Cache module is build around any topics modification date).
This is uncritical and just for our convenience.
Change History
comment:1 Changed 11 years ago by jri
- Cc dgf added
- Status changed from new to accepted
- Milestone set to Release 4.2
comment:2 Changed 11 years ago by Jörg Richter
- Status changed from accepted to closed
- Resolution set to fixed
Time plugin: modification time bubbles up (#510).
When a topic is updated, and the topic is a child of one or more composite topic/association the modification timestamp bubbles up to all the composites (including the intermediate topics).
Thus the browser cache is invalidated and an up-to-date composite is retrieved.
Close #510.
comment:3 Changed 10 years ago by Malte
- Status changed from closed to reopened
- Version 4.1.2 deleted
- Resolution fixed deleted
- Milestone Release 4.2 deleted
I still have the issue that I need to call explicitly some "dms.updateTopic(parentTopic.getId())" so that a new timestamps is set.
Apparently, when udpating topic via just using
twitterSearch.getCompositeValue().set(TWITTER_SEARCH_REFRESH_URL_URI, refreshUrl, clientState, new Directives());
the timestamp seems not to bubble up.
Can you confirm this?
comment:4 Changed 10 years ago by jri
- Module changed from deepamehta-time to deepamehta-core
- Milestone set to Release 4.4.1
Confirmed!
Yes, the timestamp bubbles up only when the update is performed via dms.update() or topic.update() or assoc.update(), but not via comp.set().
This will be fixed in DM 4.4.1 which will be released this week.
Thank you very much for reporting!
A prerequisite is addressed in #587.