optimise future fields: use regular reference when possible #418
Conversation
|
| @@ -842,6 +850,13 @@ field = func(f) { | |||
| * @return field: smart.field | |||
| */ | |||
| getFutureField: func(name, fieldType, ...eph) { | |||
| fldInfo := self.info() | |||
| if fldInfo.Value != 0 && fldInfo.Error == 0 && fldInfo.Type != constants.FTYPE_OUTPUT { | |||
There was a problem hiding this comment.
Not sure we need this. This optimisation may 'remove' one element from TIDs chain which will affect deduplication and recovery. But when we skip outputs, it seems like we almost disable the optimisation completely.
There was a problem hiding this comment.
The most risky thing here is to optionally add a non-ephemeral future-field, based on some state that may change depending on how certain races in the system are resolved. This way we will introduce a different CID (not TID) in the chain, which in tern may spoil de-duplication.
No description provided.