Make keep value retrieval in Journal more robust

[sayamindu]

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.

[sayamindu]

Proposed patch

[sayamindu]

Reassigning ticket to alsroot since he's the Journal maintainer.

[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?

[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).

[erikos]

How do we move forward with this issue?

[sascha_silbe]

Fixed in  55a4df2.