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.

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".