Code Generator Limitations and Restrictions
The generated code has the following limitations and restrictions:
- The generated apply procedure or function doesn't create any intermediate views. The procedure stacks all transformations and data processing into one large SQL statement. This stacking works only when no Text transformation is involved and when no case ID has to be generated.
- You can generate code for an Apply Activity that does text mining; however, you can only use the batch apply interface. Generating code for any activity that does text mining can be problematic; for more information, see Code for Text Mining Activities.
- The case ID for an activity should be defined in the input data. When there is no case ID in the batch apply activity, a table is required as output regardless of what the view/table output flag is set to.
- Models built using generated code are not transparent. For example, if the data is binned, model details are in terms of the bins, not the unbinned values.
- Code generated from an activity replicates exactly what the activity performed. The generated code expects that the data signature (columns names and data types) are the same as those presented to the activity. If you are missing a required column, the activity fails. To work around this issue, generate an activity that process against the data signatures that match your deployment requirements, and then generate code from that activity.
- If you run generated code with default parameter values in the same user account containing the activity from which the code is generated, you affect the state of the activity. You may have to reset and rerun the activity in order to have it return to a valid state.
Copyright © 2006, 2008, Oracle. All rights reserved.