Oracle Spatial Object Writer Feature Type Parameters

To access feature type parameters, click the gear icon on a feature type in the workspace. This opens the Feature Type Parameter Editor.

Tip: To always display the editor in Workbench, you can select View > Windows > Parameter Editor.

General

All feature types share similar General parameters, which may include Feature Type Name, Reader or Writer information, and Geometry.

In most Writer Feature Type parameter dialogs, you can also control Dynamic Schema Definitions. Some database formats accept Table or Index Qualifier prefixes on the output table feature type.

These parameters apply only to a selected feature type, not to the entire writer.

Note: If a feature type parameter listed here conflicts with a writer-level parameter, then the writer parameter will be ignored and this feature type parameter will be used.

Table Settings: General

This parameter specifies how features will be written into the destination table. Supported feature operations are described below. Note that the described behavior can be dependent on the selected options, as well as the underlying table properties.

Option

Description

If the Row Does Not Exist

If the Row Exists

Insert

The writer appends a new row to a table using input feature attributes.

The writer creates a new row using input feature attributes.

Not always applicable: if the table does not have a unique key or it has an automatically generated unique key, insertion is always possible.

The database cannot violate its key constraints; therefore, errors can occur on row insertion. For example, if there is a unique key and a user specifies the value with the feature, and the feature already exists, then Workbench logs an error. This error might be in the form of a rejected feature, or the database may stop processing altogether.

Update

The writer updates existing row(s) in a table using input feature attributes.

A selection method must be specified in the Row Selection group.

The writer rejects the input feature or logs an error if it is unable to continue.

The writer only changes values of the existing row(s) corresponding to the input feature that differ from the input feature.

Upsert

The writer appends a new row or updates an existing row(s) using input feature attributes and/or geometries.

A selection method must be specified in the Row Selection group.

The writer creates a new row using input feature attributes and/or geometries.

The writer changes values of the existing row(s) corresponding to the input feature that differ from the input feature.

It leaves other attributes untouched.

Delete

The writer deletes an existing row(s) in a table.

A selection method must be specified in the Row Selection group.

The writer rejects the input feature or logs an error if it is unable to continue.

The writer deletes existing row(s) corresponding to the input feature.

fme_db_
operation

The feature operation will be determined by the attribute fme_db_operation on each input feature.

A selection method must be specified in the Row Selection group.

The value of fme_db_operation will be processed according to the steps below.

Note: The processing steps listed below depend on a format's available Feature Operation options.

  • If the value is null, empty, or missing, it will be treated as an Insert.
  • The value will next be matched to Insert, Update, Upsert, Put, and Delete, case-insensitively.
  • If there is no match, the feature will be rejected.
  • If there is a match, the matched feature operation will be performed on the feature.

Note about earlier FME versions: To use fme_db_operation, you must set Feature Operation to this option. In previous versions of FME, you could set fme_db_operation when the destination feature type was set to Insert, Update, Upsert, or Delete. Doing this now will cause feature rejection.

 The action depends on the operation; however, in general, if nothing is specified, the value is treated as an Insert. The value is treated as an Insert.

Controls how the feature type handles destination tables or lists:

  • Use Existing – Write to an existing table or list. If the destination table/list does not exist, the translation will fail.
  • Create If Needed – Create the destination table/list if it does not exist.
  • Drop and Create – (This option is not available for all formats.) Drop the destination table/list if it exists, and then create it. The writer will drop and re-create the table before writing any features to it. Tables will be overwritten when the first input feature is processed. If no features are sent to a feature type, then the corresponding table will not be overwritten.
  • Truncate Existing – (This option is not available for all formats.) If the destination table/list does not exist, the translation will fail. Otherwise, delete all rows from the existing table or list.

When updating features, users have a choice to update, or skip, their spatial column(s). Possible options are:

  • Yes: The spatial column(s) specified by the user will be updated. IFMENulls will be written as null values and replace existing spatial values.
  • No: No spatial columns will be updated.

Feature Operation Option

Row Selection

Insert

Row Selection is ignored.

Update, Upsert, Delete

(Options may differ depending on a format's available Feature Operation options.)

A Row Selection condition needs to be specified for selecting which rows to operate on.

This parameter group offers two methods to construct the selection condition:

Match Columns

The columns specified in the corresponding column picker dialog will be used for matching destination rows. All matching rows will be selected for update, upsert, or delete. If any feature attributes corresponding to the specified match columns contain null or missing values, the feature will be rejected.

Note: This is the only supported method for Upsert feature operation.

WHERE Clause

This parameter opens a WHERE Clause Builder. You can also type a WHERE clause inline, without launching the Builder. It is optional to start the clause with the word WHERE.

The WHERE Clause Builder makes it easy for users to reference feature attribute values, destination table columns, and invoke FME functions. The WHERE clause is first evaluated as an FME expression, before being passed onto the destination database.

If the WHERE clause is incorrect or if its evaluation results in failure, the translation will fail. Otherwise, if the WHERE clause passes FME evaluation but it is SQL invalid, the feature will be rejected or the translation will fail.

For advanced users, conditional FME expressions created through the Conditional Value editor can be used to create WHERE clauses.

Tip: You can set the WHERE Clause to an attribute. This supports workspace migration and existing workflows involving fme_where. (Direct support for fme_where has been deprecated.) To advanced users who are accustomed to using fme_where, if Feature Operation is set to Update, Upsert, Delete, or fme_db_operation, an fme_where attribute that conflicts with Match Columns or WHERE Clause will result in feature rejection.

Table Creation

Specifies additional parameters (for example, table allocation characteristics) to be appended to the Oracle CREATE TABLE query used to create the output table. For example, to specify a tablespace, a STORAGE clause, and a comment for a table, the following clause could be appended:

TABLESPACE myTableSpace

STORAGE (INITIAL 50K);

COMMENT ON TABLE myTable IS ‘My new table’;

Specifies the dimension of the layer, which can currently be 2 or 3.

Directs the writer to write measures to the destination table. When this parameter is set to yes and the incoming feature does not have any measures, then null values are written. This parameter applies when writing to new tables.

The default is No.

Extents and Tolerances

Minimum X/Y/Z Ordinate and Measure Value

The minimum x, y, z, and measures values expected in the dataset. If any x/y/z/measures values are present that are less than this value, the data will still be written. However, querying the spatial index outside its extents will produce undefined results. For best spatial search performance, this value should be as close to the true minimum x/y/z/measures value as possible.

Maximum X/Y/Z Ordinate and Measure Value

The maximum x, y, z, and measures values expected in the dataset. If any x/y/z/measures values are present which are greater than this value, the data will still be written. However, querying the spatial index will produce undefined results. For best spatial search performance, this value should be as close to the true maximum x/y/z/measures value as possible.

Comparison Tolerance for X/Y/Z Ordinate and Measures

This specifies the comparison tolerance for the x, y, z, and measures values. Values in x/y/z/measures that are closer than this value are considered equal.

Table Settings: Spatial

When writing to the object model, the Oracle Spatial Object writer will create a column to hold the geometry. This column is typically called GEOM, but may be changed to any other name by using this parameter.

Note that this parameter merely specifies a default value for the geometry column. If the table already exists in the Oracle database, then the geometry column will be chosen from those defined on the existing table.

Specifies the spatial referencing information for the geometry in the table. It is specified as an integer, and corresponds to the spatial reference identifier (SRID) column in the global table MDSYS.CS_SRS.

All geometry within a given table must have the same spatial referencing. If the target table exists in the database and the value specified for Spatial SRID does not match the value contained in USER_SDO_GEOM_METADATA, the metadata's SRID will be used in place of the specified SRID.

If the SRID is not specified, tables will be created with a null value for the SRID field.

Spatial Index

Indicates whether or not spatial indexes are to be created as part of the data load. The valid choices for the object model are yes and no.

Specifies whether to drop the existing spatial index for the table.

  • Yes: The existing spatial index for the table will be dropped. A new spatial index will then be created.
  • No: The table being written already contains an index, so no spatial index will be created.

Specifies the name for the spatial index that will be created on the table. If this parameter is not specified, a spatial index name will be created based on a database sequence and the name of the table being written.

Specifies the tessellation level used to create the spatial index for the layer. The larger the number, the longer spatial index creation will take by the finer the granularity of the index.

The range is any integer between 1 and 64. The default is 0 is given, so that no levels will be specified when the index is created. Depending on the version of the Oracle Spatial database being written to, this may force it to use RTree indexing instead of fixed or hybrid indexing.

If using fixed or hybrid indexing, a positive integral value must be specified.

This specifies the number of variable-sized tiles used (per geometry) when creating a hybrid spatial index within the object model. The range is any positive integer.

If this parameter is not specified at the time when a spatial index is created, and Quadtree Levels oracle_levels is specified, fixed spatial indexing will be used in the created index.

Table Settings: Advanced

Indicates which columns' values come from sequences. The syntax for this parameter’s value is of the form:

column1:seqname1;column2:seqname2

Where "columnN" is the name of the column whose value is provided by the sequence, and "seqnameN" is the name of the sequence in the Oracle database.

As a concrete example, the value of this parameter might be:

id:mySchema.test_sequence

Where id is also specified under the User Attributes tab. mySchema.test_sequence refers to a sequence named test_sequence in the schema mySchema.

If ":seqnameN" is not given, the column's value will be provided by a sequence with the same name as the column. Sequence names are case-sensitive. The sequences will be created if they do not already exist, in which case a message will be written to the log file.

Specifies a custom SQL query to process features. This parameter is usually used for Insert, Update, and Delete operations that require custom SQL logic, such as exception handling. The values in the query can be bound by embedding :attrName in the query, where attrName is the name of the FME feature’s attribute. For example:

INSERT INTO "TEST_TABLE" ("ID", "GEOM") VALUES (:KEY, :MYGEOM)

In this example, the attribute named KEY will be taken from each feature written into the table column named “ID”. The geometry on the feature will be written into the spatial column named “GEOM”. The attributes bound in the query, including the spatial "attribute" named "MYGEOM", must be listed in the User Attributes tab. The User Attribute types should align with the column types in the table schema, although for the spatial "attribute", any User Attribute type may be specified. Further, the spatial "attribute" named "MYGEOM" must be specified in the format parameter Spatial Column. (Note that Spatial Column used to have the label Target Geometry Column Name in older FME versions.)

As another example, consider this UPDATE query:

UPDATE "TEST_TABLE" SET "GEOM"=:MYGEOM WHERE "ID"=:MYID

In this example, the attribute named MYID from each feature is matched against the column “ID”. Matching rows will have their “GEOM” column updated. The spatial column “GEOM” gets its value from the feature’s geometry. Once again, MYGEOM needs to be specified both in the User Attributes tab and in the format parameter Spatial Column.

Tip: As part of a workflow using "best practices", you should ensure that the User Attribute name and its corresponding attribute name in the bound statement are identical, inclusive of letter case. This must be true for a spatial “attribute”. For non-spatial attributes, if the pairing is identical except for letter case, the User Attribute name will prevail, unless an attribute with that name does not exist on the feature; in this case, the bound attribute name will prevail. If the bound attribute name also does not exist on the feature, the value of the nonexistent attribute should default to null.

Because of this override behavior, when there are multiple attributes on the feature with identical names except for letter case and you want to bind an attribute whose name is not all uppercase, you may need to uncheck the Uppercase Column Names parameter in the writer parameter box when you add the writer.

Note: It is not necessary (or recommended) to wrap bound attribute names in quotes: in testing, :myID behaved the same as the quoted :”myID”. If you do wrap bound attribute names in quotes, then you must do this for every bound attribute name.