Skip to main content
Solved

BulkAttributeRenamer after SQLExecutor gives error

  • December 18, 2019
  • 3 replies
  • 17 views
L

Dear FME'ers,

 

I have a question about the conflict resolution of SQLExecutors and FeatureReaders.

I found the issue when I was reading data from a PostgreSQL database. Some of the initiator's attribute names where the same as in the result of my SQL. Therefore I used the option 'conflict resolution'. This because I supposed that the data of the initiator is then overwritten by the data of the SQL script (for the attributes with conflicting names).

After that I tried to rename the output attributes with the help of a BulkAttributeRenamer but got an error. This is not the case when I set the conflict resolution to 'Use Initiator'. There is also no problem when I use a regular AttributeRenamer

 

If I'm obliged to remove all conflicting attributes then what is the use of the conflict resolution? Or is this a problem related to the BulkAttributeRenamer?

 

In attachment an example of my question with some extra info. I was able to recreate the issue by reading an Excel file with a FeatureReader:

 

Our FME version: 2019.1.3.0 (20191007 - Build 19642 - WIN64)

we use python 3.6+

 

Thanks in advance!

Kind Regards,

Louis Put

 

Best answer by markatsafe

@louisput Thanks for reporting this and for creating a simple reproduction workflow of the problem. The attribute conflict resolution of the FeatureReader should work as you described. We'll get this addressed.

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.

3 replies

M
Forum|alt.badge.img+2
  • markatsafe
  • 1891 replies
  • Best Answer
  • December 18, 2019

@louisput Thanks for reporting this and for creating a simple reproduction workflow of the problem. The attribute conflict resolution of the FeatureReader should work as you described. We'll get this addressed.

erik_jan
Contributor
Forum|alt.badge.img+22
  • erik_janContributor
  • Contributor
  • 2179 replies
  • December 18, 2019

A possible work-around could be using aliases in the SQL statement in the SQLExecutor, like:

Select attr1 as myfirstattribute

, attr2 as mysecondattribute

From table

This will rename the attributes from the database to myfirstattribute and mysecondattribute and allows you to avoid the conflicts.

 

Another work-around would be using the BulkAttributeRenamer before the SQLExecutor or FeatureReader to rename the source attributes and not the database attributes to avoid conflicts.

 

Hope this helps solving the issue.

L
  • louisput
  • Author
  • 6 replies
  • December 19, 2019

A possible work-around could be using aliases in the SQL statement in the SQLExecutor, like:

Select attr1 as myfirstattribute

, attr2 as mysecondattribute

From table

This will rename the attributes from the database to myfirstattribute and mysecondattribute and allows you to avoid the conflicts.

 

Another work-around would be using the BulkAttributeRenamer before the SQLExecutor or FeatureReader to rename the source attributes and not the database attributes to avoid conflicts.

 

Hope this helps solving the issue.

Thanks for the reply. I will rename the attributes of my initiator and remove conflicting attributes before the SQLExecutor. With the help aliases I will then set the SQL output attributes names.

Community Stats

32,079
Posts
121,808
Replies
39,710
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.