[
https://issues.apache.org/jira/browse/NIFI-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199636#comment-15199636
]
Joseph Witt commented on NIFI-1118:
-----------------------------------
[~jskora] Totally understand regarding time and want to be both respectful of
it and the impact of the change.
The bar to substantively change existing default behavior should be relatively
high. That means the justification for it should be solid. Right now we don't
have that. True our reasoning for having this behavior is weak too but it is
there and has been there for a long time so we must honor it or be really
deliberate in changing it.
So let's say we are changing it for sake of thinking this through more. If we
do so we must be clear about what we're doing to help the user compensate for
the change. As initially proposed it would mean the flow would come up invalid
until the user did something. Has the documentation of the processor been
updated to help the user? Would the validation message itself explain what to
do? Has the migration guide been updated for this?
Let's discuss further the ripple effects of existing behavior change.
Typically such flows with split text are followed by ExtractText or
RouteOnContent and those regex entries could be affected.
This is just a really dangerous path. I think we need to honor their behavior.
Then I think we need to discuss how to avoid being in such cases later. The
extension registry w/ versioned components is probably the right answer.
Because you as a developer should have more flexibility to evolve than this.
So, in short, this is why I wanted to have a more dynamic conversation as there
are enough perspectives and complications that it would help.
Thanks
Joe
> Enable SplitText processor to limit line length and filter header lines
> -----------------------------------------------------------------------
>
> Key: NIFI-1118
> URL: https://issues.apache.org/jira/browse/NIFI-1118
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Reporter: Mark Bean
> Assignee: Joe Skora
> Fix For: 0.6.0
>
>
> Include the following functionality to the SplitText processor:
> 1) Maximum size limit of the split file(s)
> A new split file will be created if the next line to be added to the current
> split file exceeds a user-defined maximum file size
> 2) Header line marker
> User-defined character(s) can be used to identify the header line(s) of the
> data file rather than a predetermined number of lines
> These changes are additions, not a replacement of any property or behavior.
> In the case of header line marker, the existing property "Header Line Count"
> must be zero for the new property and behavior to be used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
