[jira] Commented: (IBATIS-569) Simulate mode for Ibator Plugins
[ https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12659482#action_12659482 ] Jeff Butler commented on IBATIS-569: I just checked in changes for this to SVN. They are as described above, except that the class to extend is IbatorRulesDelegate - NOT IbatorRulesProxy. Delegate is a more appropriate pattern for what I was describing. Let me know what you think. Simulate mode for Ibator Plugins Key: IBATIS-569 URL: https://issues.apache.org/jira/browse/IBATIS-569 Project: iBatis for Java Issue Type: Wish Components: Tools Affects Versions: 2.3.3 Reporter: Dan Turkenkopf Assignee: Jeff Butler As I'm playing with creating Ibator plugins for various purposes, I'm running into the issue of conflicting actions. For example, I have one plugin that optionally removes the insert method from the DAO class, but I have another one that creates a new method that calls the insert method. When running the two of them on the same table, my generated DAO has compile errors. Since the plugins shouldn't know anything about each other, I need some way to know whether the DAO's insert method is actually generated or not. I played around with a way of tracking generation state at the IbatorPluginAggregator level, but the timing of component creation doesn't appear to be in the right order for what I'm doing (the daoImplementationGenerated method is called before the daoInsertMethodGenerated method). My suggestion is to run through the generation process twice - once to determine which components should be generated, and a second time to actually generate them. Granted, this would slow down generation, but since it's an out-of-band process anyway, speed should be less important. And this would allow plugins to be independent but still react to whether another plugin changes the generated output. I'm willing to continue working on this and submit a patch, but wanted to get some feedback before going too much further. Thanks, Dan Turkenkopf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IBATIS-569) Simulate mode for Ibator Plugins
[
https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12659221#action_12659221
]
Jeff Butler commented on IBATIS-569:
The initialized method currently has the opportunity to override the default
rules (setRules()). However, when I mentioned the proxy class, I really hadn't
thought it through completely. IbatorRules as it stands would be difficult to
proxy. I'll definitely fix that.
My first thought is to do something very simple - turn IbatorRules into an
Interface, rework the three supplied implementations, and supply a basic rules
proxy class. Then each plugin could easily override one or more rules from the
default calculated rules. Pseudo code like this:
public class MyPlugin extends IbatorPluginAdapter {
public void initialized(IntrospectedTable introspectedTable) {
IbatorRule rules = introspectedTable.getRules();
MyRules myRules = new MyRules(rules);
introspectedTable.setRules(myRules);
}
}
public class MyRules extends IbatorRulesProxy {
public MyRules (IbatorRules ibatorRules) {
super(ibatorRules);
}
@Override
public boolean generateInsert() {
return false;
}
}
This way you could chain rules implementations together in different plugins if
required, but we wouldn't have to do anything too complex. I think this is a
fairly rare use case so I don't want to overdesign.
Simulate mode for Ibator Plugins
Key: IBATIS-569
URL: https://issues.apache.org/jira/browse/IBATIS-569
Project: iBatis for Java
Issue Type: Wish
Components: Tools
Affects Versions: 2.3.3
Reporter: Dan Turkenkopf
As I'm playing with creating Ibator plugins for various purposes, I'm running
into the issue of conflicting actions.
For example, I have one plugin that optionally removes the insert method from
the DAO class, but I have another one that creates a new method that calls
the insert method. When running the two of them on the same table, my
generated DAO has compile errors.
Since the plugins shouldn't know anything about each other, I need some way
to know whether the DAO's insert method is actually generated or not.
I played around with a way of tracking generation state at the
IbatorPluginAggregator level, but the timing of component creation doesn't
appear to be in the right order for what I'm doing (the
daoImplementationGenerated method is called before the
daoInsertMethodGenerated method).
My suggestion is to run through the generation process twice - once to
determine which components should be generated, and a second time to actually
generate them. Granted, this would slow down generation, but since it's an
out-of-band process anyway, speed should be less important. And this would
allow plugins to be independent but still react to whether another plugin
changes the generated output.
I'm willing to continue working on this and submit a patch, but wanted to get
some feedback before going too much further.
Thanks,
Dan Turkenkopf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IBATIS-569) Simulate mode for Ibator Plugins
[ https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12659180#action_12659180 ] Dan Turkenkopf commented on IBATIS-569: --- Doing a little more thinking about this, I wonder if allowing plugins to register as Rules providers would work. In the initialized method, a plugin could register with the IbatorContext as a rules provider (i.e. implements an IbatorRulesProvider interface). Then when another class gets the IbatorRules from the IntrospectedTable it could call out to all the rules providers and ask for their response. If any of them return false, then the overall answer would be false as well. I think I could put that mechanism together pretty quickly and it would definitely meet my needs. Thoughts? Simulate mode for Ibator Plugins Key: IBATIS-569 URL: https://issues.apache.org/jira/browse/IBATIS-569 Project: iBatis for Java Issue Type: Wish Components: Tools Affects Versions: 2.3.3 Reporter: Dan Turkenkopf As I'm playing with creating Ibator plugins for various purposes, I'm running into the issue of conflicting actions. For example, I have one plugin that optionally removes the insert method from the DAO class, but I have another one that creates a new method that calls the insert method. When running the two of them on the same table, my generated DAO has compile errors. Since the plugins shouldn't know anything about each other, I need some way to know whether the DAO's insert method is actually generated or not. I played around with a way of tracking generation state at the IbatorPluginAggregator level, but the timing of component creation doesn't appear to be in the right order for what I'm doing (the daoImplementationGenerated method is called before the daoInsertMethodGenerated method). My suggestion is to run through the generation process twice - once to determine which components should be generated, and a second time to actually generate them. Granted, this would slow down generation, but since it's an out-of-band process anyway, speed should be less important. And this would allow plugins to be independent but still react to whether another plugin changes the generated output. I'm willing to continue working on this and submit a patch, but wanted to get some feedback before going too much further. Thanks, Dan Turkenkopf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IBATIS-569) Simulate mode for Ibator Plugins
[ https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12658995#action_12658995 ] Dan Turkenkopf commented on IBATIS-569: --- Hi Jeff, I saw the initialized method. That's a really nice feature that will make things a lot easier. That said, I don't think it applies in this case since the plugins are entirely unrelated - I just happened to run them on the same table at the same time. I think that's probably the proper behavior - leaving the plugins independent of each other and only figuring out things through the basic Ibator functionality. The IbatorRules approach might work better though. It would suggest that any plugin that halts any of the basic Ibator generated functionality would have to inform the Rules object somehow so that all other plugins are made aware. You'd need to add a way to set the IbatorRules object for a table, of course. I'm still pondering the implications, but a couple of things jump out at me. You'd have to have some way for different plugins to weigh in on whether they'd be generating a piece of functionality - so that implies some kind of chaining like the IbatorPluginAggregator does I think. Also, the way this would work best is if all these indicators can be set ahead of the actual generation - otherwise order becomes very important. So the initialized method is probably the right time for this hook. Of course plugins are free to not register their intent (or to lie about it) and not generate the methods, but this could work as a relatively low-impact mechanism. Any ideas on how you'd want the proxying to work? Simulate mode for Ibator Plugins Key: IBATIS-569 URL: https://issues.apache.org/jira/browse/IBATIS-569 Project: iBatis for Java Issue Type: Wish Components: Tools Affects Versions: 2.3.3 Reporter: Dan Turkenkopf As I'm playing with creating Ibator plugins for various purposes, I'm running into the issue of conflicting actions. For example, I have one plugin that optionally removes the insert method from the DAO class, but I have another one that creates a new method that calls the insert method. When running the two of them on the same table, my generated DAO has compile errors. Since the plugins shouldn't know anything about each other, I need some way to know whether the DAO's insert method is actually generated or not. I played around with a way of tracking generation state at the IbatorPluginAggregator level, but the timing of component creation doesn't appear to be in the right order for what I'm doing (the daoImplementationGenerated method is called before the daoInsertMethodGenerated method). My suggestion is to run through the generation process twice - once to determine which components should be generated, and a second time to actually generate them. Granted, this would slow down generation, but since it's an out-of-band process anyway, speed should be less important. And this would allow plugins to be independent but still react to whether another plugin changes the generated output. I'm willing to continue working on this and submit a patch, but wanted to get some feedback before going too much further. Thanks, Dan Turkenkopf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IBATIS-569) Simulate mode for Ibator Plugins
[ https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12658576#action_12658576 ] Jeff Butler commented on IBATIS-569: Hi Dan, There are a couple of new things that could help: 1. The plugin API now contains an initialized method. This method is called after database introspection and before any of the code generation methods. One plugin could use this method to set attributes for use by another plugin. 2. As far as simulate mode, there's something sort of like that already. All code generation in Ibator is controlled by an instance of IbatorRules. This class contains methods that enable/disable all the different code fragments produced by Ibator. In your plugin, you could make a simple proxy of the calculated IbatorRules object that overrides certain behaviors, and then replace the calculated rules object with your new instance. For example, your first plugin could turn off the insert method completely - and then the second plugin could query the rules object to see that insert is disabled. Simulate mode for Ibator Plugins Key: IBATIS-569 URL: https://issues.apache.org/jira/browse/IBATIS-569 Project: iBatis for Java Issue Type: Wish Components: Tools Affects Versions: 2.3.3 Reporter: Dan Turkenkopf As I'm playing with creating Ibator plugins for various purposes, I'm running into the issue of conflicting actions. For example, I have one plugin that optionally removes the insert method from the DAO class, but I have another one that creates a new method that calls the insert method. When running the two of them on the same table, my generated DAO has compile errors. Since the plugins shouldn't know anything about each other, I need some way to know whether the DAO's insert method is actually generated or not. I played around with a way of tracking generation state at the IbatorPluginAggregator level, but the timing of component creation doesn't appear to be in the right order for what I'm doing (the daoImplementationGenerated method is called before the daoInsertMethodGenerated method). My suggestion is to run through the generation process twice - once to determine which components should be generated, and a second time to actually generate them. Granted, this would slow down generation, but since it's an out-of-band process anyway, speed should be less important. And this would allow plugins to be independent but still react to whether another plugin changes the generated output. I'm willing to continue working on this and submit a patch, but wanted to get some feedback before going too much further. Thanks, Dan Turkenkopf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
