Jon, There is very little overhead really. The answer more generally has to do with history. Expression language was added later in the game and there can be different scopes to what a given EL statement has access to. Some EL are evaluated against flowfiles and some arent. We didn't have a good way to show users this information though this has recently improved. It also has to do with 'evaluation time' meaning processors might evaluate some properties frequently/while executing a task (as would be the case when EL statements have a given flowfile in scope) or during enabling/scheduling such as pulling a property value they intend to honor throughout an entire runtime.
I suspect at this point that we can make most properties (not enumerations most likely) EL enabled. But, each one requires review/consideration to ensure the processor is coded to use it correctly. Alternatively, we could explore making all text entry fields allow users to explicitly state 'this is a variable and here is the variable name' (but in a cool UI way) and then the actual value used would come from the variable registry for that process group. This would be something we can do across the board as it wouldnt' change the processor's logic/behavior at all. Variables get set at and retained throughout the life of a processor run. If a used variable is changed we'd automatically stop/start each impacted component/processor so it wouldnt' require any additional review/changes in processor properties. ThanksOn Wed, Oct 24, 2018 at 2:46 PM Jonathan Meran <jonathan.me...@sonos.com> wrote: > > Hello there, > Regarding expression language properties, why aren't all or most properties > enabled by default. > > Is there substantial processor overhead on these? > > Thanks, > Jon > > On 10/24/18, 1:49 PM, "Joe Witt" <joe.w...@gmail.com> wrote: > > Mark > > There are two scenarios here to discuss: > 1) What do to with sensitive properties > 2) What to do with properties that dont allow expression language > statements > > For #1 we dont send those properties into the registry and they are > set (properly) in each environment where the secret belongs. All good > as that doesn't change the flow definition. > > For #2 we should just look at which properties are causing trouble and > see about expression language enabling them. So please share > precisely which ones you're hitting where that would help you out and > lets see what can be done. > > Thanks > On Wed, Oct 24, 2018 at 1:39 PM Mark Littleton > <marklittle...@hotmail.co.uk> wrote: > > > > Hi Everyone, > > > > I'm currently doing a lot of work with Nifi and recently we have been > trying to come up with a solution to a problem. We installed Nifi registry > backed by our Git repository for versioning our flows. This has worked out > great for us as we can now track the version of our flows correctly and make > sure they are backed up in source control. > > > > However when we want to do deployment between our Development Nifi > cluster and our Qa Nifi cluster we have to ofcourse change some values. These > could be amqp queues, directories on the file system etc. > > > > So ofcourse we use variables so that we can configure the values > without it being detected as a change to the flow. A problem arises however > when we need to configure an option that does not support expression > language. For example the host name of the amqp processors. > > > > This leaves us in a situation where a change to the flow is detected. > The only real option I have as far as I can see is to clone the flows and > have one for each environment which I don't like at all. > > > > Is anyone else struggling with similar issues. If so how are you > handling It? > > > > Sent from my Sony Xperia™ smartphone > >
