ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler (JIRA)" <ibatis-...@incubator.apache.org>
Subject [jira] Commented: (IBATIS-492) Allow Abator configuration to extend model objects from existing classes
Date Fri, 07 Mar 2008 22:09:46 GMT

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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message