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-569) Simulate mode for Ibator Plugins
Date Fri, 26 Dec 2008 04:06:44 GMT

    [ https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

public class MyPlugin extends IbatorPluginAdapter {
  public void initialized(IntrospectedTable introspectedTable) {
    IbatorRule rules = introspectedTable.getRules();
    MyRules myRules = new MyRules(rules);

public class MyRules extends IbatorRulesProxy {
  public MyRules (IbatorRules ibatorRules) {

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

View raw message