Skip to main content
  • EN

I have followed this pattern of a workflow for years, where I maintain attribute names and data types in a spreadsheet for different databases, and I import those names and values using the Import... dialog within the AttributeCreator as one of the last steps of a data workflow.

​

When I import values, here's what I usually have in the AttributeCreator:

​

Output Attribute Value

attribute{0}.name AreaName

attribute{0}.fme_data_type fme_varchar(64)

​

Now that the AttributeCreator has a data type in the dialog, should I still follow this pattern?

 

How does this new data type parameter work with dynamic workflows?

I understand the use case for data types in the AttributeCreator/AttributeManager is rather using the automatic feature type definition. The idea is that the data types you define in the AttributeCreator are automatically carried to the writer feature type definition and therefore the output data. Anyway, you might want to have a look at the twitch session @mark2atsafe​ recorded last week, they definitely explain it better: https://www.twitch.tv/videos/1829135745

If you are maintaining a spreadsheet with your database schemas, you might as well use a dynamic feature type with that spreadsheet as a schema source. Or just the database as a schema source and no need for keeping the spreadsheet at all. Always reading the schemas with a Reader as a Resource or a Schema Reader, obvíously, you don't want to read the data from your databases just to keep the schema. Or maybe if your database schemas are not changing at all you can make do just importing the feature types from the database themselves, whether in the AttributeManager or in the writer feature type. Does that make sense?

I understand the use case for data types in the AttributeCreator/AttributeManager is rather using the automatic feature type definition. The idea is that the data types you define in the AttributeCreator are automatically carried to the writer feature type definition and therefore the output data. Anyway, you might want to have a look at the twitch session @mark2atsafe​ recorded last week, they definitely explain it better: https://www.twitch.tv/videos/1829135745

If you are maintaining a spreadsheet with your database schemas, you might as well use a dynamic feature type with that spreadsheet as a schema source. Or just the database as a schema source and no need for keeping the spreadsheet at all. Always reading the schemas with a Reader as a Resource or a Schema Reader, obvíously, you don't want to read the data from your databases just to keep the schema. Or maybe if your database schemas are not changing at all you can make do just importing the feature types from the database themselves, whether in the AttributeManager or in the writer feature type. Does that make sense?

Thank you @fgiron​ I did happen to watch that video and it was extremely helpful. It has really changed the way I work! I'm loving using the AttributeManager to set data types and just setting the FeatureWriter to Automatic.

Thank you @fgiron​ I did happen to watch that video and it was extremely helpful. It has really changed the way I work! I'm loving using the AttributeManager to set data types and just setting the FeatureWriter to Automatic.

I'm glad you're enjoying the new data types feature 🙂 Thanks for the feedback!

Reply


Community Stats

30,162
Posts
114,483
Replies
37,809
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.