Solved

BulkAttributeRenamer after SQLExecutor gives error

  • 18 December 2019
  • 3 replies
  • 3 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

 

icon

Best answer by markatsafe 18 December 2019, 17:16

View original

3 replies

M
Badge +2

@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
Rank
Userlevel 2
Badge +12

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

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.

Reply


Community Stats

28,670
Posts
109,366
Replies
36,531
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.