You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if the storage failed, an error should be thrown, it's just too error prone to return a boolean nobody is going to check.
save_result returns false in case of some failures, but throws in other cases (FormatUnsuitable for example). I doubt that in case of a failures, any implementation will actually return false. Instead they likely all throw an error and fail. Thus, the only value you may effectively get from this process is "true".
Also, it's actually not well defined what would fail and what would result in false. So this is an interoperability issue.
The only reason for a boolean I could find it that if you have two save_result nodes that then you can save partial results, but that seems like a strange thing if other issues throw anyway.
Proposed solution:
His proposal:
I think it's cleaner to return nothing (null) or return the original data
Context: There's no void in openEO, null is a strange replacement. Effectively, then we could also clarify that it's always true and throws otherwise. Changing to null doesn't bring any real benefit here. So we could return the original data instead. I actually think this was already proposed somewhere else, too. On the other hand, you can simply connect any following processes after save_result with the previous node and get the same behavior. Should we clarify that save_result always throws and otherwise always returns true? Or should we completely redefine the return value?
Additional context:
Should go through PSC if a breaking change is proposed.
The text was updated successfully, but these errors were encountered:
We discussed this today and keep the boolean result. All options where chaining is required can be solved otherwise and may just be back-end limitation. This way we keep the option to later use the return value for something more useful, e.g. to return a vector data cube for each generated STAC item.
Process ID: save_result (and save_model)
Describe the issue:
@soxofaan has a good point in #304 (comment) :
save_result returns false in case of some failures, but throws in other cases (FormatUnsuitable for example). I doubt that in case of a failures, any implementation will actually return false. Instead they likely all throw an error and fail. Thus, the only value you may effectively get from this process is "true".
Also, it's actually not well defined what would fail and what would result in false. So this is an interoperability issue.
The only reason for a boolean I could find it that if you have two save_result nodes that then you can save partial results, but that seems like a strange thing if other issues throw anyway.
Proposed solution:
His proposal:
Context: There's no void in openEO, null is a strange replacement. Effectively, then we could also clarify that it's always true and throws otherwise. Changing to null doesn't bring any real benefit here. So we could return the original data instead. I actually think this was already proposed somewhere else, too. On the other hand, you can simply connect any following processes after save_result with the previous node and get the same behavior. Should we clarify that save_result always throws and otherwise always returns true? Or should we completely redefine the return value?
Additional context:
Should go through PSC if a breaking change is proposed.
The text was updated successfully, but these errors were encountered: