Question

exposing data on reader: intended behaviour?

G
Badge +3
Hi,

 

 

I was wondering i this is intendend.

 

 

On a reader i choose to not expose certain attributes, say SetA

 

I thought this would exclude them from further operations.

 

 

I do a comparison with another set, SetB. This set has an attribute wich should be, on passing certain conditions, passed to SetA. This attribute is one of the none-exposed in SetA., as SetA is not allowed to dictate its value.

 

Now i found that not exposing the attribute on set A does not exclude it from the operation, it fouls up the result. Even after not exposing it, i still need to remove the attribute.

 

 

Seems somewhat uselss to me, that option to expose or not on the reader, or not ?

 

 

 

 

 

 

 

Gio

12 replies

takashi
Rank
Userlevel 2
Badge +17
Hi Gio,

 

 

I think it's an intended behavior. In my understanding:

 

"Expose" and "Hide" are operations on the user interface of Workbench, those will never affect internal data contents. "Create" and "Remove" will affect real data.

 

 

Takashi
david_r
Rank
Userlevel 4
Hi Gio,

 

 

I agree with Takashi, I think this is as intended.

 

 

David
G
Badge +3
Hi all,

 

 

Does this then serve no purpose whatsoever and at all in fact?

 

Just cosmetics.

 

 

 

For if one makes a large workspace, and kinda forgot one non-exposed certain attributes, one would be wondering WTF?! After some testing and searching one discovers "Ah, i non-exposed those"

 

As to actualy not releaving one of remvoing attributes, one can only conclude "this serves no purpose whatsoever".

 

 

 

;)

 

 

 

When i first saw this option i was like "Hey! Thats handy, saves me removing attributes"....NOT.

 

 

Anyways im a forewarned man now, and the wiser. :0

 

 

tx for making this clear to me.

 

 

Go

 

G
Badge +3
on the meaning of "expose" i like to dissagree.

 

 

Expose is ment to expose variables wich either reside in memory or are internal to some dataformat or even transformer.

 

Like Autocad wich has a huge list of attributes hidden.

 

 Or the spatialrelator, wich has (nested even) some very usefull attributes.

 

 When they are exposed the become available as attributes.

 

When i do not expose these, they are not available to subsequent processing.

 

 

 

On the reader however, the expose option is actually more a hide/unhide option, as these are attributes its working on.

 

 And aparently hiding does not exclude them for subsequent operations. That makes it lame in my opinion.

 

So they should rename the option to "hide/unhide" and maybe flag the workspace:

 

"Be aware! functional attributes are hidden!"

 

 

Gio
takashi
Rank
Userlevel 2
Badge +17
I think there are some principles.

 

By default, User Attributes are exposed and Format Attributes are hidden.

 

Attributes which will be added by a transformer will be basically exposed.

 

But attributes whose names will be determined at run-time will not be exposed automatically.

 

And also attributes which will be created through Python / Tcl scripts or SQL statements will not be exposed automatically (and attributes which will be removed through Python / Tcl scripts will not be hidden automatically).

 

 

We can expose attributes with the AttributeExposer, but there is not "AttributeHider" transformer. Few transformers have "Attributes to Hide" parameter. I sometimes use "Attributes to Hide" parameter of PythonCaller (script does nothing).
david_r
Rank
Userlevel 4
I agree the distinctin between exposing/hiding an attribute and deleting an attribute can be confusing.

 

 

The distinction is between "design-time" and "run-time", and the attributes available between the two are not necessarily always the same.

 

 

Consider the following example:

 

 

 

 

In the Workbench (design-time), the Cloner will show that both Attribute_A and Attribute_B are available, but if you look at the two features actually output by the Logger (run-time), you will see that it's either Attribute_A or Attribute_B. No single feature entering the Logger will have both Attribute_A and Attribute_B set, even though you do get that impression from looking at the transformer attributes above.

 

 

That is, generally speaking, the difference in FME between attribute availability at design-time versus run-time.

 

 

All this just to say that it is sometimes impossible for FME to either know or to correctly represent the differences in availability of attributes between design-time and run-time. There are therefore two different mechanisms in FME to manipulate attributes:

 

  • Exposing/hiding an attribute is a design-time feature
  • Deleting an attribute is a run-time feature
Hopefully this makes it a bit clearer.

 

 

David
G
Badge +3
Hi David,

 

 

 

 

The example with the cloner is not realy examplatory as cloner doenst relate the inputs, its just a copier...

 

If u would (unconditionnaly) merge them it would show both attributes in one log.

 

The attributes are set on either one of the objects, so it stands to logic that you cannot see them simultaneously if u choose to view either one.(as yoou say yourself)

 

I think an (eperienced) fmeista sees and understands this without logging. ;) and will not fall for possible confusion the cloner could induce.

 

 

 

I think i do understand this.

 

But i also understand that there is no point whasoever to the expose option on the reader.

 

So i conclude it is jut an hide/unhide option that does nothing like on the Pythoncaller.

 

 

 

Gio

 

 

 

 

david_r
Rank
Userlevel 4
Hi Gio,

 

 

I admit the example with the Cloner was contrived, but I think it demonstrates the differences between design-time and run-tim, which was my point :-)

 

 

There is a point to the expose/hide option on the reader, and that is to declutter the workspace without having to explicitly add an AttributeRemover just after. Personally, I use it quite a bit and find it a nice feature.

 

 

David
G
Badge +3
Hi,

 

 

I can see the use of decluttering as such.

 

I still prefer a keeper or remover, depening on wich makes me click the least.

 

 

Reason is it will exclude attributes from operations. Wich is more important to me then just cosmetic-decluttering. Also i assume it saves memory and processtime.

 

 

 

Greetings

 

Gio
gazza
Badge +5
Hi Gio,

 

 

It was my understanding that the behaviour you are getting is a bug.  I've just installed the 2015 Beta and in that unexposing the attribute in the reader means it isn't available later on.  From memory the 2014 betas have also fixed it but I can't confirm that right now.

 

 

Regards

 

 

Gary
takashi
Rank
Userlevel 2
Badge +17
Gio, you're right. Removing useless attributes saves memory usage and processing time. I think, however, there are cases where "cosmetic-decluttering" will be also useful.

 

Imagine a case where source feature has hundreds attributes and they should be written into destination dataset with the same schema after transforming geometry. In such a case, you can use Dynamic Schema simply. And also hiding (not removing) all the attributes could be very effective from viewpoint of development efficiency and maintainability.

 

In my personal opinion, development efficiency and maintainability are also important as a professional, and I think this is one of why exposing option exists.

 

Case by case.
G
Badge +3
Hi Takashi,

 

 

With a huge schema i would opt for a different approach to use inputschema as inputschema.

 

Particularly because of performance issue's.

 

 

I For instance, i would exclude all non-used attributes form the processstream, and later, reunite them.

 

 

 

Developmentwise, i don't see the point. All you need to keep in mind is the input schema. Need one you just disabeld? Enable it!

 

 

But i see Garry reports it might indeed be a bug.

 

 

Tx all,

 

 

Laters!

 

 

 

Reply


Community Stats

28,666
Posts
109,342
Replies
36,535
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.