Skip to main content
Question

Valid expression ans still a red wheel on transformer


gio
Contributor
Forum|alt.badge.img+15
  • Contributor

This expression

 

(@Value(part_count)==0 && @Value(OBJECTID)==1)?1:

 

(@Value(part_count)==0 && @Value(OBJECTID)!=1)?@Value(feature[-1].Dag_GB)+1:@Value(feature[-1].Dag_GB)

 

It is a working partitioniser.

It works by first using a counter (counter4 in picture) in group by mode on wathever you want to partitionise. Data must be sorted first (mandatory).

Then it runs the expression on the resulting counter attribute.

 

This is way faster then aggregating(listbuilding) by group, counting and then deaggregating(exploding).

 

It is faster because it does not block. It streams nicely.

 

But the wheels stays red! (attributecreator4)

 

 

This is annoying.

A known bug?

(using 2018 B18301)

7 replies

gio
Contributor
Forum|alt.badge.img+15
  • Author
  • Contributor
  • October 11, 2019

btw objectid= 1 is just to identify first row of dataset.

It could als be (and was) xlsx_row_id= 1 etc.


ebygomm
Influencer
Forum|alt.badge.img+39
  • Influencer
  • October 11, 2019

I've seen similar when using adjacent attribute handling in an AttributeCreator - the process works fine, so i normally just annotate it as you have done to say it's not really an error and can be ignored.

What is the name of the attribute you are creating in the AttributeCreator?


gio
Contributor
Forum|alt.badge.img+15
  • Author
  • Contributor
  • October 14, 2019
ebygomm wrote:

I've seen similar when using adjacent attribute handling in an AttributeCreator - the process works fine, so i normally just annotate it as you have done to say it's not really an error and can be ignored.

What is the name of the attribute you are creating in the AttributeCreator?

Hi @egomm

 

I created the missing "adjacent" feature in the row prior to the expression.

Apparently this is allowed..lol.

I create "feature[-1].Dag_GB" in a adjacent enabled attribute creator whilst the attribute "Dag_GB" does not even exist at that point..

 

Of course creating the attribute (non adjacent) in a attribute creator prior to the one with the expression also works. (but requires a attribute creator to be present)

 

 

 

 

 


ebygomm
Influencer
Forum|alt.badge.img+39
  • Influencer
  • October 14, 2019
gio wrote:

Hi @egomm

 

I created the missing "adjacent" feature in the row prior to the expression.

Apparently this is allowed..lol.

I create "feature[-1].Dag_GB" in a adjacent enabled attribute creator whilst the attribute "Dag_GB" does not even exist at that point..

 

Of course creating the attribute (non adjacent) in a attribute creator prior to the one with the expression also works. (but requires a attribute creator to be present)

 

 

 

 

 

Yes, it's a choice between what's more irritating, adding an extra attribute creator that's not really needed or the red cog!


gio
Contributor
Forum|alt.badge.img+15
  • Author
  • Contributor
  • October 16, 2019

Update!

Creating "feature[-1].Dag_GB" resolves the red cog, yes.

But it is useless as there is no actual relation to "Dag_GB".

This means that subsequent records do not get updated, but refer to its set value every time.

 

Only solution is therefore, creating the attribute in a attributecreator prior to the one runnning the expression, so need to create "Dag_GB" with an arbitrary value.

 


mark2atsafe
Safer
Forum|alt.badge.img+45
  • Safer
  • October 16, 2019

Hmmm. I don't know if it's a bug or a feature, but that does look like if you create a new attribute (say xxxx) in an AttributeCreator, then the next line cannot allow feature[-1].xxxx.

On the one hand, that makes sense. If the prior feature hasn't been processed, then it can't have an xxxx value. I'm guessing we know that attribute can't exist, and flag it as such.

On the other hand, this does more or less run as you'd expect. Even though feature[-1].xxxx doesn't - and can't possibly - exist, the substitution parameter should take care of that.

So I'm wavering between a bug and works-as-designed.

I think I'll raise this with the developers. I honestly don't know if it's fixable without rewriting a whole bunch of underlying functionality - which they would be reluctant to do - but we'll see.

As noted, the workaround would be to use two AttributeCreators. I know it looks a bit untidy, but you could put them inside a collapsible bookmark, or even make a custom transformer.

I hope this helps. I'll let you know what I hear back from the developers.


mark2atsafe
Safer
Forum|alt.badge.img+45
  • Safer
  • October 16, 2019
mark2atsafe wrote:

Hmmm. I don't know if it's a bug or a feature, but that does look like if you create a new attribute (say xxxx) in an AttributeCreator, then the next line cannot allow feature[-1].xxxx.

On the one hand, that makes sense. If the prior feature hasn't been processed, then it can't have an xxxx value. I'm guessing we know that attribute can't exist, and flag it as such.

On the other hand, this does more or less run as you'd expect. Even though feature[-1].xxxx doesn't - and can't possibly - exist, the substitution parameter should take care of that.

So I'm wavering between a bug and works-as-designed.

I think I'll raise this with the developers. I honestly don't know if it's fixable without rewriting a whole bunch of underlying functionality - which they would be reluctant to do - but we'll see.

As noted, the workaround would be to use two AttributeCreators. I know it looks a bit untidy, but you could put them inside a collapsible bookmark, or even make a custom transformer.

I hope this helps. I'll let you know what I hear back from the developers.

This is already filed as FMEDESKTOP-8948. It's low priority because there is an easy workaround. Having said that, it's flagged as a quick and easy win, so we might see a fix soon. We'll just have to wait and see I'm afraid.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings