This is because the types in the FeatureWriter depend on what is possible / required in the format.

I second the answer from @nielsgerrits, in addition the ones in the AttributeManager/AttributeCreatator etc are FME’s definitions of the various attributes are. Being able to define these in the AttirbuteManager/AttributeCreator can help with workflows which do not already have a defined schema - FME will map these types to a type in the writer. 

It’s important to keep in mind that, as far as I am aware, they do not have an effect on FME transformers themselves and are just labels to be used by the writer to help with the mapping - although sometimes this would be nice (e.g., JSONTemplator). 

In the past, before these types were able to be set, and FME mapped the attribute type wrong in the writer you had to manually overwrite it in the writer which made some automated workflows a litte more difficult. 

I would say most of the time you can just ignore the internal types and just let FME do it’s best.

Here’s an interesting example, below I have created a attribute called STRING with the calue “I am a string” and I tagged it with the type “logical”. This has been auto picked up on the shapefile writer. After writing you can see the output attribute value is a “?” because this is just a nonsense type. There was no warning in the logfile for this. 

In contrast I can set a value that makes sense for a logical value. e.g., “YES”. In the below example you can see that the output value in the shapefile now resolves to ”true”. What you can also see is that my Tester still fails the test if I try and test for “true” - This is just to highlight that these types are only really intended for the writer. 

 

Hopefully the example shows how these types in FME transformers should be set. What I didn’t expand on though was why the writer might have different types to FME - But it is indeed as @nielsgerrits said. In your example it looks like you’re wrtiing to Postgres? from what I can see it appears to be more typical for SQL to have the int number represent the number of bytes rather than the number of bits which is what FME uses. Here’s a list of the FME Datatypes: https://docs.safe.com/fme/html/FME-Form-Documentation/FME-ReadersWriters/!FeatureTypeProperties/FME-Data-Types.htm

And here are the list of types available for the Postgres writer: 
https://docs.safe.com/fme/html/FME-Form-Documentation/FME-ReadersWriters/postgres/user-attributes.htm

 


 

To me it sounds pretty confusing Int8 is 8bits or 8bytes and you can only see its 8bits because the other options are Int16,Int32,Int64 and its 8bytes because the other options are Int1,Int2,Int4,Int8.

--It should be Int8 to Int64, and databases are creating columns using the function INT(1) to INT(8) which is still Int8 to Int64.--

Edit: i was wrong here. INT(1) means it stores a number with a length of 1 character. So it’s the character width and not the storage-width. Why FME uses Int1 tot Int8 is some other reason.