The <table> Element

The <table> element is used to select a table in the database for introspection. Selected tables will cause the following objects to be generated for each table:

An iBATIS formatted SQL Map file
A set of classes that form the "model" of the table including:
- A class to match the primary key of the table (if the table has a primary key).
- A class to match the fields in the table that are not in the primary key, and non BLOB fields. This class will extend the primary key if there is one.
- A class to hold any BLOB fields in the table, if there are any. This class will extend one of the two previous classes depending on the configuration of the table.
- A class that is used to generate dynamic where clauses in the different "by example" methods (selectByExample, deleteByExample). This class may, or may not, extend one of the other model classes depending on the current generator set and the structure of the table.
(Optionally) A DAO interface and class

At least one <table> element must be specified as a required child element of the <abatorContext> element. You can specify unlimited table elements.

Database Identifiers

Abator tries to deal with the case sensitivity of database identifiers automatically. In most cases, Abator is able to find tables regardless of what you specify for catalog, schema, and tableName attributes. Abator's process follows these steps:

If either of the catalog, schema, or tableName attributes contain a space, then Abator will look for tables based on the exact case specified. In this case, Abator will automatically delimit the table identifiers in the generated SQL.
Else if the database reports that identifiers are stored in upper case, Abator will automatically convert any table identifier to upper case.
Else if the database reports that identifiers are stored in lower case, Abator will automatically convert any table identifier to lower case.
Else Abator will look for tables based on the exact case specified.

In most cases, this process works perfectly. However, there are cases where it will fail. For example, suppose you create a table like this:

  create table "myTable" (
     ...some columns
  )

Because the table name is delimited, most databases will create the table with the exact case specified - even if the database normally stores identifiers in upper case. In this instance, you should specify the attribute delimitIdentifiers="true" in the table configuration.

Required Attributes

Attribute	Description
tableName	The name of the database table (not including the schema or catalog). The specified value can contain SQL wildcards if so desired.

Optional Attributes

Attribute Description

schema The database schema - not required if your database does not use schemas, or if there is a default schema. The specified value can contain SQL wildcards if so desired.

catalog The database catalog - not required if your database does not use catalogs, or if there is a default catalog.

alias If specified, this value will be used to alias the table and all column names in any generated SQL select statement. Column names will be aliased with the pattern alias_actualColumnName.

domainObjectName The base name from which generated object names will be generated. If not specified, Abator will generate a name automatically based on the tableName. The name (either specified here, or generated automatically) will be used to compute generated domain class names and DAO class names.

enableInsert

Signifies whether an insert statement should be generated.

The default is true.

enableSelectByPrimaryKey

Signifies whether a select by primary key statement should be generated. Regardless of this setting, the statement will not be generated if the table does not have a primary key.

The default is true.

enableSelectByExample

Signifies whether a select by example statement should be generated. This statement enables many different dynamic queries to be generated at run time.

The default is true.

enableUpdateByPrimaryKey

Signifies whether an update by primary key statement should be generated. Regardless of this setting, the statement will not be generated if the table does not have a primary key.

The default is true.

enableDeleteByPrimaryKey

Signifies whether an delete by primary key statement should be generated. Regardless of this setting, the statement will not be generated if the table does not have a primary key.

The default is true.

enableDeleteByExample

Signifies whether a delete by example statement should be generated. This statement enables many different dynamic deletes to be generated at run time.

The default is true.

enableCountByExample

Signifies whether a count by example statement should be generated. This statement will return the number of rows in a table that match an example.

The default is true.

enableUpdateByExample

Signifies whether an update by example statement should be generated. This statement will update rows in a table that match an example. This method is not available in the legacy generator set. If true, an update by example "selective" statement will also be generated. The "selective" statement will only update columns where the corresponding value in the record parameter is non-null.

The default is true.

selectByPrimaryKeyQueryId This value will be added to the select list of the select by primary key statement in this form: "'<value>' as QUERYID". This can be useful for identifying queries in DBA tracing tools at run time. If you use thus value, you should specify a unique id for every different query generated by Abator.

selectByExampleQueryId This value will be added to the select list of the select by example statement in this form: "'<value>' as QUERYID". This can be useful for identifying queries in DBA tracing tools at run time. If you use thus value, you should specify a unique id for every different query generated by Abator.

modelType

This property is used to override the default model type if you desire to do so for this table. If not specified, Abator will generate domain objects based on the context default model type. The model type defines how Abator will generate domain classes. With some model types Abator will generate a single domain class for each table, with others Abator may generate different classes depending on the structure of the table. The property supports these values:

conditional	This model is similar to the hierarchical model except that a separate class will not be generated if that separate class would only contain one field. So if a table has only one primary key field, that field will be merged into the base record class.
flat	This model generates only one domain class for any table. The class will hold all fields in the table.
hierarchical	This model is the same as the model shipped with the initial versions of Abator. This model will generate a primary key class if the table has a primary key, another class that holds any BLOB columns in the table, and another class that holds the remaining fields. There is an appropriate inheritance relationship between the classes.

escapeWildcards

Signifies whether SQL wildcards ('_' and '%') in the schema and tableName should be escaped when searching for columns. This is required by some drivers if the schema or tableName includes an SQL wildcard (for example, if a table name is MY_TABLE, some drivers require that the underscore character be escaped).

The default is false.

delimitIdentifiers

Signifies whether Abator should use the exact case specified when searching for tables and then delimit the identifiers in the generated SQL. See the discussion above for more details.

The delimiter characters are specified on the <abatorContext> element.

The default is false unless the catalog, schema, or tableName attributes contain a space, then true.

Child Elements

Supported Properties

This table lists the properties of the default SQL Map generators that can be specified with the <property> child element:

Property Name	Property Values
useActualColumnNames	If true, then Abator will use column names as returned from the database metadata as the properties of the generated domain objects. If false (default), Abator will attempt to camel case the returned names. In either event, the name can be specified explicitly by the <columnOverride> element in which case this property will be ignored for the specified column. For example, suppose a table contains a column START_DATE. If the value of this property is "true", then Abator will generate the property name as `START_DATE` - meaning that the getters and setters for the value will be `getSTART_DATE()` and `setSTART_DATE()`. If the value of this property is false, then Abator will generate the property name as `startDate` - meaning that the getters and setters for the value will be `getStartDate()` and `setStartDate()`. The default value is false.
ignoreQualifiersAtRuntime	If true, then Abator will not add the schema or catalog to the table name in the generated SQL. This is useful if you have tables with the same name in several schemas - you can use Abator to generate objects based on the table in one schema, but not include the schema for runtime. The default value is false.
rootClass	This property can be used to specify a root class for all generated Java model objects. Abator will specify this value as the super class of the primary key object, if the table has a primary key, or the record object otherwise. The value specified in this property will override the `rootClass` property set on the Java Model Generator configuration if any is set. Important: If Abator is able to load the root class, Abator will not override a property in the root class that exactly matches a property that Abator would normally generate. An exact match of a property is defined as follows Property name matches exactly Property is of the same type Property has a "getter" method Property has a "setter" method You may use the "rootClasspath" property of the <javaModelGenerator> element to add entries to the rootClass lookup classpath if necessary. If specified, the value of this property should be a fully qualified class name (like com.mycompany.MyRootClass).
rootInterface	This property can be used to specify a super interface for all generated DAO interface objects. The value specified in this property will override the `rootInterface` property set on the DAO Generator configuration if any is set. Important: Abator does not verify that the interface exists, or is a valid Java interface. If specified, the value of this property should be a fully qualified interface name (like com.mycompany.MyRootInterface).
runtimeTableName	If you specify a value for this property, than Abator will use that value as the table name in the generated SQL rather than the `tableName` as configured above. This is especially useful on Oracle if you want to generate objects to use a public synonym. In that case, you will need to generate the objects against the actual table that the synonym points to, then specify the synonym name in this property. You should also specify the `ignoreQualifiersAtRuntime` property in most cases with public synonyms.
useColumnIndexes	If true, then Abator will generate resultMaps that use column index rather than column name in the result mappings. This is useful when a table has column names differentiated only by the case of the name (e.g. "first name" and "First Name"). There is a slight performance benefit with this support also. The default value is false.

Example

This element specifies that we always want to generate code for a table called MYTABLE in schema MYSCHEMA. We also want to ignore a column called "fred" in the table, and we want to override the column "BEG_DATE" so that the generated property name will be "startDate".

<table tableName="MYTABLE" schema="MYSCHEMA">
  <ignoreColumn column="fred"/>
  <columnOverride column="BEG_DATE" property="startDate"/>
</table>