What's New in Ibator
Version 1.2.0
Announcements
- With version 1.2, Abator is renamed to Apache iBATIS Ibator. Several changes
have been made to the XML configuration as well as the Java API. See the
Migrating from Abator page for detailed
information about changes needed to existing Abator configuration files.
Bugs Fixed
- Fixed the JavaTypeResolver so that columns with unsupported data types
may be overridden by configuration.
- Fixed IBATIS-523 - a bug in the pre-release version of the EqualsHashCodePlugin
- Fixed IBATIS-542 - upgrade the build to Ant version 1.7.1
Enhacements
- Ibator now includes a plugin mechanism. This mechanism can be used to
add to or modify the code generated by Ibator. If you have previously
extended one of Abator's code generators to change their behavior, we
strongly suggest that you move to a plugin. See the
<ibatorPlugin> page
for detailed information.
- Ibator ships with the following plugins:
- A plugin that will generate an SQL Map Config File
(
org.apache.ibatis.ibator.plugins.SqlMapConfigPlugin
)
- A plugin that will make generated model classes Serialiable
(
org.apache.ibatis.ibator.plugins.SerializablePlugin
)
- A plugin that will add
equals
and hashCode
methods to generated model classes
(org.apache.ibatis.ibator.plugins.EqualsHashCodePlugin
)
- Added support for "runtimeCatalog" and "runtimeSchema" properties to the
<table>
configuration element. Thanks to Dan Turkenkopf for the idea and the
patch!
- New generated method - insertSelective. This method will allow you to use
column defaults on a table definition on insert
- Added the ability to specify a that DAO implementation classes be in a
seperate package from the DAO interface classes.
Changes from Abator
There are several breaking changes between Ibator and Abator. This list
details the changes, and has methods of resolving the differences.
- JSE 5.0 or higher is required for Ibator
- Ibator does not contain the "legacy" code generators from Abator. You must
choose "Ibatis2Java2" or "Ibatis2Java5" as a target runtime - and code generated from
Ibator is compatible with iBATIS version 2.2.0 or higher only. If you are
using an earlier version of iBATIS - upgrade! If you are not able to upgrade,
then you must continue to use Abator.
- The classloading strategy in Ibator is changed from Abator. In all cases, we now recommend
specifying the classpath external to Ibator and we further recommend that you do not use
the
<classPathEntry>
element. You may specify classpath entries
if you feel you must, but those entries will only be used when loading JDBC drivers
of Java model root classes. If you write a custom extension to Ibator, or a plugin,
you must specify that classpath entry external to Ibator.
- The API for extending Ibator is significantly changed from Abator.
In most cases, implementations of the old Abator interfaces should
be converted to Ibator plugins. See the
Extending Ibator for more information.
- The
afterXXXGenerationHook
methods have been removed from
all Ibator supplied implementations of the core interfaces. If you
were extending an Ibator supplied implementation to make use of these methods,
then you must migrate your code to an Ibator plugin.
- The build has been significantly modified and now includes an Emma based
code coverage report.
- Changes to the XML configuration file are required. See the
Migrating from Abator page for detailed
information
Version 1.1.0
Announcements
- The next release of Abator will require JRE 5.0 or higher.
- Java2 is now the default generator set. This will cause different code to be
generated if you have not specified a generator set previously. To remedy this,
set the generator set to "Legacy".
New Generated Methods
Abator will generate these new methods:
- countByExample
- This method will return an integer representing the number of rows in a table
that match the given criteria.
- updateByExample
- 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
- Fixed bug for corner case where a criteria class is created, but no criteria
are set.
- Fixed a bug that caused the JavaModelGenerator's "trimStrings" property to fail
- Fixed the XML file merger so that internal entities are preserved
- Fixed the XML configuration parser so that external entities are handled properly
- Fixed bug - incorrect datatype mapping for JDBC BIT datatype
- Fixed bug where Abator generated incorrect properties for certain database columns
(for example, if the column name is I_NAME)
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 or alias
- 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, or the
Oracle reference page for an example.
- Added support for delimiting SQL identifiers for the use cases where identifiers
contain spaces or SQL reserved words.
See the <table>,
<abatorContext>,
and <columnOverride>
reference pages for more information.
- Added SYBASE dialect for generated keys.
See the <generatedKey>
reference page for more information.
- Added DB2_MF (DB2 on Main Frames) dialect for generated keys.
See the <generatedKey>
reference page for more information.
- Abator will now automatically escape identifiers that contain the $ or # characters
as these characters have special meaning in iBATIS configuration files.
- Added a
clear
method to the generated example classes (in the Java2 and Java5
generator sets only). This allows reuse of these classes.
- Added the ability to specify that result maps should use column indexes rather
than column names in the result mappings. Primary use cases for this
support include:
- When tables have columns whose name is only differentiated by
case (e.g. "first name" and "First Name")
- When you want to make the selects as fast as possible (there is a slight
performance benefit when using column indexes)
See the <table>
reference page for more information.
- Made the generated Example and Criteria classes extendable. Added some documentation
about how to extend these classes. See the
Extending the Example Classes
reference page for more information.
- Made the legacy DAOs extendable.
- Added the ability to provide a renaming rule for columns. This is for the
use case where columns have a common prefix that should be removed before
calculating the property name. See the
<columnRenamingRule>
reference page for more information.
- Added support for persisting a configuration to XML - this to enable
a graphical editor in the future.
- Add afterXXXGenerationHook() methods in all generators to enable adding
extra Java code or XML elements to any generated object. This will make
it easier to create customized generators.
- API change to allow generating with selected contexts rather than
the entire config file.
- API change to allow generating with selected tables rather than
the entire config file.
- Exposed new support for selecting tables and/or contexts to the
command line and the Ant task - this has added an advanced syntax to the command
line for Abator. See the
Running Abator reference page for more information.
rootClass
and rootInterface
may now be specified for each table.
See the <table>
reference page for more information.
- If a
rootClass
is specified for any table, Abator will now check in the
rootClass to see if a generated property already exists in the root class. If it does,
Abator will not generate the property. The <javaModelGenerator> element now
accepts a property to specify the classpath of the rootClass
. See the
<javaModelGenerator>
reference page for more information. Thanks to Ashok Madhavan for the beginnings
of this code.
- Allowed specifying a type (pre or post) for the generated key element. See the
<generatedKey>
reference page for more information.
- Added a comment generator interface to enable generation of custom comments.
See the <commentGenerator>
reference page for more information.
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:
- 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
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
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
- 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.