From the oracle data, are you able to identify what fields are meant to be datetimes?

In the DateTimeConverter you can specify either the attribute (_creation_instance) or to use the value that _creation_instance (@Value(_creation_instance)) contains

Hi @hkingsbury ,

Sorry, I don’t get “_creation_instance” values from the Reader. I get the input parameters and “fme_feature_type_name” value. Could the problem be in the configuration of Reader?

Tkanks!

Well, my solution abuses BulkAttributeRenamer, RegEx and List Attribute naming convention, and is complex…..but it works.

Frankly though, I would probably just write something in PythonCaller, but the below works for out-of-the-box Transformers.

Step 1 is to get Attributes that are Date/Time from the Schema Features from a FeatureReader

 

Step 2 is to Join these with the Dynamic Feature Reader Output.  In this case, there are 11 Date/Time Attributes for the 100 Sample Features, so this gives 11 x 100 Joins.  This gives a “Grid” of Values, where each of the 1,100 Features represents 1 Date/Time Attribute “Cell” 11 columns of date/time Attributes x 100 Features to give 1,100 Features to operate on.

Step 3 is to temporarily rename each Date/Time Dynamic Attribute to static/known Name by abusing BulkAttributeRenamer, which can work well as a type of  “Dynamic Schema AttributeCreator”

 

So now we have a “Table” from this that is _count (Workspace Unique Feature ID), fme_feature_type (Table Name), name (of date/time Attribute) and “_date_col” which is the temporary known and exposed name of the Date/Time Attribute

Step 4 is to find which Attribute “Cells” have a valid FME Date/Time value, and convert them to Y-m-d
 

Step 5 is to know  a bit about how Lists work in being just a collection of Attributes that happen to have their Name as in a format like _list{1}.Attribute Name .  If we remove the _list{1}. part of the List Attribute Name by again abusing BulkAttributeRenamer, then they become just standard Attributes as far as the Workspace is concerned.

 

So now we use a FeatureJoiner with Override from the Right set up to replace the original FME format Date/Time Attribute Values with the new DateTimeConverter String values.

So waaay more complex than I expected to “Dynamically” find Date/Time Attributes in a Dynamic Reader situation.  It would be a lot simpler if could have a Transformer like AttributeCreator that could perform in a dynamic “Attribute Scan” type mode that could traverse all Attributes and use Eg. Conditional Values. 🤨

Or as above, I would probably just write a Custom PythonCaller...

The easiest way is probably to get a SchemaScanner to generate a valid schema feature?

I tried a bit and this might be harder than I suspected initially. The SchemaScanner does not seem to work as I hoped it would.

From the oracle data, are you able to identify what fields are meant to be datetimes?

In the DateTimeConverter you can specify either the attribute (_creation_instance) or to use the value that _creation_instance (@Value(_creation_instance)) contains

 

I would try what is suggested here.

_creation_instance is just an example of an attribute, substitute it with the attribute that contains the field names