You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by "Ryan Shelley (JIRA)" <ib...@incubator.apache.org> on 2008/03/07 09:27:46 UTC
[jira] Created: (IBATIS-492) Allow Abator configuration to extend
model objects from existing classes.
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.
[jira] Commented: (IBATIS-492) Allow Abator configuration to extend
model objects from existing classes
Posted by "Ryan Shelley (JIRA)" <ib...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/IBATIS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576297#action_12576297 ]
Ryan Shelley commented on IBATIS-492:
-------------------------------------
I'll check out the version in SVN and try it out. Is it as simple as adding a "rootClass" attribute to the "table" element?
I can absolutely understand the desire to no imply structure of the superclass. The callbacks were simply a "nice to have" idea, and if the SVN provides the superclassing functionality, that's 100% of what I need, everything else was gravy.
At some time in the near future, I may look at extending the JavaModelGenerator class to apply callbacks, however, how would one instruct Abator to use the custom JavaModelGenerator class? I don't see an attribute in the javaModelGenerator element to define a custom class.
> 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.
[jira] Commented: (IBATIS-492) Allow Abator configuration to extend
model objects from existing classes.
Posted by "Daniel Kasmeroglu (JIRA)" <ib...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/IBATIS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576083#action_12576083 ]
Daniel Kasmeroglu commented on IBATIS-492:
------------------------------------------
It would be better if the classes would be created using a factory. The default factory would generate the instances as usual. Custom factories might create some specialized extensions of these model classes (f.e. with the above mentionen none-table-elements or convenience functions).
> 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.
[jira] Closed: (IBATIS-492) Allow Abator configuration to extend
model objects from existing classes
Posted by "Jeff Butler (JIRA)" <ib...@incubator.apache.org>.
[ 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.
[jira] Commented: (IBATIS-492) Allow Abator configuration to extend
model objects from existing classes
Posted by "Jeff Butler (JIRA)" <ib...@incubator.apache.org>.
[ 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.