[
https://issues.apache.org/jira/browse/IBATIS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576401#action_12576401
]
Jeff Butler commented on IBATIS-492:
------------------------------------
<javaModelGenerator type="...">
Take a look at the documentation page for extending Abator, or the
documentation page for the <javaModelGenerator> element.
> 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
> Priority: Minor
>
> 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.
