[
https://issues.apache.org/jira/browse/IBATIS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Butler closed IBATIS-492.
------------------------------
Resolution: Fixed
Fixed already (sort of) in SVN.
Abator in SVN already allows specifying a root class for each table
individually.
As far as onWrite/onUpdate...we won't add this support as it makes a tremendous
assumption about the structure of superclasses that are outside the realm of
Abator. If you need this support in your environment, you could implement your
own JavaModelGenerator to generate classes this way.
As far as the factory goes, this is already a function of iBATIS (see
ResultObjectFactory configuration). It has no bearing on Abator.
> 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.
