Skip to main content
Solved

Why does AttributeRenamer cut data type width?


I'm importing data from a ArcGIS .gdb to a POSTGIS DB using FME Desktop 2016. For this I need first to rename single attribute names using the AttributeRenamer transformer. My poblem is that, reader attributes with width 254 (data type "text") are automatically transformed to writer width 200 (type "varchar"). Why does FME cut the width of the attributes, is it a bug?

However, this issue only appears when I use an AttribruteRenamer. I also tryied the BulkAttributeRenamer, which retrieves the same. Any ideas?

Thanks

Best answer by redgeographics

Does this happen when you have the user attributes set to "Automatic"? In that case it will match the types of the input attributes (within the limitations of the writer format of course) but since you rename the attribute it can't find an input match so, in case of PostGIS, it defaults to a varchar 200.

You can fix this by switching to manual and then editing the type yourself.

Hope this helps.

View original
Did this help you find an answer to your question?

4 replies

redgeographics
Celebrity
Forum|alt.badge.img+47
  • Celebrity
  • Best Answer
  • November 10, 2017

Does this happen when you have the user attributes set to "Automatic"? In that case it will match the types of the input attributes (within the limitations of the writer format of course) but since you rename the attribute it can't find an input match so, in case of PostGIS, it defaults to a varchar 200.

You can fix this by switching to manual and then editing the type yourself.

Hope this helps.


fmelizard
Contributor
Forum|alt.badge.img+17
  • Contributor
  • November 11, 2017
redgeographics wrote:

Does this happen when you have the user attributes set to "Automatic"? In that case it will match the types of the input attributes (within the limitations of the writer format of course) but since you rename the attribute it can't find an input match so, in case of PostGIS, it defaults to a varchar 200.

You can fix this by switching to manual and then editing the type yourself.

Hope this helps.

I strongly believe @redgeographics answer is correct. Long run we'd like to propagate types through attribute renames during design time in workbench, but for now, the "automatic" mode won't find a match and so the default kicks in. If you adjust the schema to "manual" then you can change it. More evidence for us to address this.

 


@redgeographics: We were using "automatic" in our team as we have a wide range of tables with quite often attribute changes and a lot of people working with the same workbenches. Therefore my second question:

Is there a transformer that can rename an attribute without losing this connection to the Input and consequently keeping the Input width for the writer instead of actual setting of the default PostGIS width of varchar 200?


redgeographics
Celebrity
Forum|alt.badge.img+47
nicolas_varela wrote:

@redgeographics: We were using "automatic" in our team as we have a wide range of tables with quite often attribute changes and a lot of people working with the same workbenches. Therefore my second question:

Is there a transformer that can rename an attribute without losing this connection to the Input and consequently keeping the Input width for the writer instead of actual setting of the default PostGIS width of varchar 200?

I'm afraid not: the matching of attributes is done purely by name. As soon as that changes it loses connection.

 

 

How dynamic are your processes? Do you often get different input and output structures?

 

 


Reply


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