What's New in Ibator

Version 1.2.1

Bugs Fixed


Version 1.2.0


Bugs Fixed


Changes from Abator

There are several breaking changes between Ibator and Abator. This list details the changes, and has methods of resolving the differences.

Version 1.1.0


New Generated Methods

Abator will generate these new methods:

This method will return an integer representing the number of rows in a table that match the given criteria.
This method will update all rows in a table that match a given criteria. This method is available in the Java2 and Java5 generator sets only. There is also a "selective" version of the method that only updates certain columns of a table (the selective version of this method is probably the more useful version to use in most situations).

Bugs Fixed

Miscellaneous Changes

Version 1.0.0

Generator Sets

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:

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

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:

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.
This model generates only one domain class for any table. The class will hold all fields in the table.
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.


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.

Miscellaneous Changes