What's New in Abator
Version 1.0.1 Miscellaneous Changes
- Added the ability to specify properties to ignore qualifiers and change runtime
table names in the generated SQL for a table. Primary use cases for this
support include:
- Generating objects for a table that has a public synonym in Oracle
- Generating objects for a table that exists in many schemas, and the
schema will be selected at runtime
See the <table>
reference page for more information.
Generator Sets (Version 1.0.0)
A generator set is a set of
code generators (SQL Map Generator, Java Model Generator, DAO Generator, and Java Type Resolver).
Abator now ships three different generator sets. The generated code from these three
generator sets is slightly different, and the use of the generated objects is slightly
different too. The concepts are exactly the same. With the newer generator sets, the
"by example" methods have been vastly improved. It is now possible to generate
virtually any WHERE clause (including IN and BETWEEN predicates). Lastly, the new
generator sets generate much more concise code - the DAOs and SQL Maps are of
normal size, and there are no extraneous methods. The example class in the new generator
sets encapsulates all the function needed to generate dynamic queries.
The three generator sets shipped with Abator are as follows:
- Legacy
- This generator set generates code that is the same as previous versions of
Abator. There are some limitations with this generator set and we strongly
recommend that you choose one of the other sets. However, this set remains
the default for now. This generator set will likely be removed in a future
version of Abator.
- Java2
- This generator set generates code that is compatible with iBATIS versions 2.2.0 and
higher. With this generator set the "by example" methods are much more powerful
than in the legacy set. It is now possible to generate
virtually unlimited SQL WHERE clauses with Abator generated code (including "IN"
and "BETWEEN" clauses). This generator set will likely become the default set in a
future version of Abator.
- Java5
- This generator set has the same capabilities as the Java2 generator set with the
added feature of generating code that is JSE 5.0 compliant using parameterized
types and annotations.
Important: code generated with the Java2 or Java5 generator sets is not 100%
compatible with code generated with the Legacy set - especially in the use of the
"by example" methods. Also note that the "by example" methods in these generator sets rely
on iBATIS dynamic SQL support that is missing in iBATIS versions prior to version 2.2.0.
A generator set is selected with the generatorSet
attribute of the
<abatorContext>
element. See the
<abatorContext> reference page for
more information.
Use of the example classes is different with the different generator sets. See the
Example Class Usage page for more
information.
Model Types (Version 1.0.0)
A model type is used to give you more control over the types of domain objects
generated by Abator. Abator now supports three different types of domain models
as follows:
- 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. This model type is the default.
Note that this model type may generate classes that are not 100%
with classes generated in previous versions of Abator.
- 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.
Model types can be specified as a default for an entire context, and you may
override the default for each table in a context. See the
<abatorContext> reference page for
more information about setting the context default..
See the <table>
reference page for more information about setting a model type for specific tables.
Important: the default value is conditional - this is a non-backward compatible
change from previous versions of Abator.
updateByPrimaryKeySelective (Version 1.0.0)
This is a new mapped SQL statement, and new DAO method, that will only
update columns whose corresponding properties in the parameter class are non-null.
This can be used to update certain
columns in a record without needing to update the entire record.
Important: any column that is mapped to a primitive type
will always be updated.
Version 1.0.0 Miscellaneous Changes
- Added the ability to specify a table alias. This aids in reuse of generated
SQL map elements. See the <table>
reference page for more information.
- Fixed the XML file merger so that extraneous blank lines at the end of the
file are removed.
- Added the ability to specify a type handler for table columns.
See the <columnOverride>
reference page for more information.
- Added the ability to specify the visibility of the DAO "by example" methods.
This allows you to make the methods private for internal use only.
See the <daoGenerator>
reference page for more information.
- Added the ability to override the naming convention for DAO method names.
See the <daoGenerator>
reference page for more information.
- Added the ability to specify wildcards for schema or tableName in a table
configuration. This will allow generation of many tables with a simple
XML configuration.
See the <table>
reference page for more information.
- Added the ability to escape wildcard characters in schema or table names
if required by the driver. See the <table>
reference page for more information.
- Added the ability to suppress JSE 5.0 type warning messages for non-parameterized
types if you are using the Legacy or Java2 generator sets in a JSE 5.0 environment.
See the <abatorContext>
reference page for more information.
- Added the ability to specify an external properties file for passing
parameters into an Abator configuration file (like the iBATIS properties
file). See the <properties>
reference page for more information.
- The Ant task now supports a "verbose" attribute. See the
Running Abator page for more information.
- The Ant task now supports a nested property set for passing values into
an Abator configuration file. See the
Running Abator page for more information.