Opened 14 years ago

Closed 12 years ago

Last modified 11 years ago

#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)

keep.patch (634 bytes) - added by sayamindu 14 years ago.
Proposed patch

Download all attachments as: .zip

Change History (8)

Changed 14 years ago by sayamindu

Proposed patch

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: 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 14 years ago by erikos

How do we move forward with this issue?

comment:6 Changed 12 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.

comment:7 Changed 11 years ago by dnarvaez

  • Milestone 0.96 deleted

Milestone 0.96 deleted

Note: See TracTickets for help on using tickets.