#1591 closed defect (fixed)
Make keep value retrieval in Journal more robust
Reported by: | sayamindu | Owned by: | alsroot |
---|---|---|---|
Priority: | Unspecified by Maintainer | Milestone: | |
Component: | Sugar | Version: | 0.95.x |
Severity: | Major | Keywords: | |
Cc: | Distribution/OS: | ||
Bug Status: | Unconfirmed |
Description
The keep value retrieval code in the journal expects the data to be int, however, sometimes it is not. The attached patch tries to fix that.
Attachments (1)
Change History (8)
Changed 14 years ago by sayamindu
comment:1 Changed 14 years ago by sayamindu
- Owner changed from tomeu to alsroot
- Status changed from new to assigned
Reassigning ticket to alsroot since he's the Journal maintainer.
comment:2 Changed 14 years ago by alsroot
- Keywords r+ added; r? removed
comment:3 follow-up: ↓ 4 Changed 14 years ago by alsroot
- Keywords r! added; r+ removed
oops, sorry
what about making such checks(and #1590) on ds level(could be also in place where shell writes ds entries, but I guess ds is enough) and do not place check code to intermediate code?
comment:4 in reply to: ↑ 3 Changed 14 years ago by sascha_silbe
Replying to alsroot:
oops, sorry
what about making such checks(and #1590) on ds level(could be also in place where shell writes ds entries, but I guess ds is enough) and do not place check code to intermediate code?
I would prefer the data store to stay as generic and metadata-agnostic as possible and let the UI handle unexpected data. It should also be in the read path, not the write one to provide robustness in cases of filesystem (or hardware) failures and misbehaving DS clients (i.e. activities), as has been argued on some other ticket as well.
We might decide to store special entries for the actions view (this has been discussed on the ML several months ago IIRC), so I'd prefer the generic data store access code to not enforce a certain set of properties to be present. Besides, there is no single place were this could be done (see #1197, #1198).
comment:5 Changed 13 years ago by erikos
How do we move forward with this issue?
comment:6 Changed 11 years ago by sascha_silbe
- Distribution/OS Unspecified deleted
- Keywords r! removed
- Milestone changed from Unspecified by Release Team to 0.96
- Resolution set to fixed
- Severity changed from Unspecified to Major
- Status changed from assigned to closed
- Version changed from Unspecified to 0.95.x
Fixed in 55a4df2.
Proposed patch