Remove return type dependency of filter step
We have already been talking about using exceptions in a workflow and we agreed we should keep their number low as exceptions require more resources. I am still opening this PR now, because I think we should remove the return type dependency from steps.
Thinking about filters: if a filter must be used too much times, then the workflow is possibly badly constructed. Big data feeds should be filtered as much as possible prior to processing with Port.
What do you think?
Thinking about filters: if a filter must be used too much times, then the workflow is possibly badly constructed. Big data feeds should be filtered as much as possible prior to processing with Port.
I don’t agree that if the filter is used on many (or all) items, the filtering should be done outside of Port. We have the filters exactly in order to enable users to filter and write their data in one workflow.
if we decide to focus on performance this shouldn't be modified.
One of the focus points of ddeboer/data-import was not performance per se, but rather using as little memory as possible. After all, when processing large amounts of data with PHP, memory can be a problem.
Actually, I kind thought myself with this.
@Baachi is right, exceptions would be a huge performance hit, which we probably don't want, even if performance is not our number one priority.
Also, this exception is probably still too much filter specific, so I propose the following:
Define return status codes in the Step interface: SKIP (0), SUCCESS (1), FAILURE (-1) (for now). Steps should return these or null (actually I would even force to return one of these codes, otherwise it is treated as a failure, once we drop 5.x support in favour of 7.x, we could even return typehing for integer).
@sagikazarmark we can also use constants for that which have these values.
In case it wasn't clear: I meant them to be constants with the given integer values. I would rather work with integer than string status codes.
Sounds good. :+1: