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
Hi Gio,
I agree with Takashi, I think this is as intended.
David
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
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
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).
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
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
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
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
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
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.
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!
