Allow Abator configuration to extend model objects from existing classes.
-------------------------------------------------------------------------
Key: IBATIS-492
URL: https://issues.apache.org/jira/browse/IBATIS-492
Project: iBatis for Java
Issue Type: Improvement
Components: Build/Deployment
Affects Versions: 2.3.1
Reporter: Ryan Shelley
Currently, only javaModelGenerator definitions can declare a rootClass,
however, it would extremely helpful to allow individual table elements to also
use a rootClass that would override the javaModelGenerator's rootClass. This
would allow a developer to create custom superclasses for individual Models.
The purpose of creating superclasses for Models would be to allow
non-table-specific meta-data to be attached to individual model objects, or
common methods between specific Model types. Additionally, each custom
superclass could be required to implement an iBATIS interface defining an
abstract onUpdate and onWrite method.
Ultimately, Abator would have a new rootClass attribute on the table element.
If declared on the table, Abator would generate new Model classes extended from
this custom superclass. Additionally, each setter would call the superclass's
onUpdate method, and each insert/update/delete would call the superclass's
onWrite method. This would allow the developer to create various meta-data
fields associated to the Model, and also provide a means of automatically
updating meta-data fields when a column-mapped attribute is updated or the
model is modified in the database.
Functionally, this would allow the developer to have a flag denoting if the
Model has changed. When the column-mapped attribute is updated through the
member's setter, behind the scenes, the Model would call onUpdate, which the
developer defines to change the flag to "true". The developer then has some
code to iterate through a list of Models and if any flag is set to "true", it
is updated in the database. This update would then call the onWrite method of
the supeclass, which the developer defines to flip the flag back to "false".
The difficulty with the onWrite method is synchronizing it with transactions so
that onWrite is only invoked on successfully committed Models.
Regardless, the ability to extend the abator-generated classes from custom
superclasses to add meta-data to the models would be a huge benefit, even
without onUpdate/onWrite methods.
The reason I bring this improvement up, is that currently, the only way to
accomplish this functionality is to extend the abator-generated classes to new
classes (making the abator-generated classes superclasses). This would then
require new SQLMaps, ResultMaps, and DAO methods to implement, and ultimately,
the developer's application would have two versions of the same Model floating
around to enable different functionality. If the abator-generated models are
extended from custom superclasses, zero additional work would be required of
the developer to implement, and allow the meta-data enhanced methods to be
returned from abator-generated SQLMaps.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
