Skip to main content
Solved

Why does AttributeRenamer cut data type width?

  • November 9, 2017
  • 4 replies
  • 31 views
N

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.

This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

4 replies

redgeographics
Celebrity
Forum|alt.badge.img+60
  • redgeographicsCelebrity
  • Celebrity
  • 3704 replies
  • 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.

FME rocks! \m/
fmelizard
Safer
Forum|alt.badge.img+20
  • fmelizardSafer
  • Safer
  • 3719 replies
  • November 11, 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.

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.

 

N

@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+60
  • redgeographicsCelebrity
  • Celebrity
  • 3704 replies
  • November 16, 2017

@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?

 

 

FME rocks! \m/

Community Stats

32,090
Posts
121,869
Replies
39,731
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
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.