how to support joins in the delegating translator

[gamvi01]

Hi

I have a scenario where the delegating translator need to support joins.

HarnessExecutionFactory extends BaseDelegatingExecutionFactory

and Test1Translator extends ExecutionFactory

In the vdb i have

<translator name="test1..delegated-translator" type="translator-harness">

        <property name="DelegateName" value="test1.delegating-translator"/>

    </translator>

<translator name="test1.delegating-translator" type="h2"/>

Test1Translator needs joins . How do i correct it in HarnessExecutionFactory ?

[rareddy]

Override the required "supports" method on your HarnessExecutionFactory class.

[gamvi01]

Is there any other way apart from that?  Do you mean to do a setSupport* of different stuff in the harnessexecutionFactory as everytime a new setSupport* added to the translator needed to be added to harnessExecutionFactory.

[rareddy]

It is YOUR custom translator, you can devise anyway other ways you need further extensions.

[gamvi01]

I didnt understand what you said. what extensions do i need to write in harnessexecutionfactory ?

[markaddleman]

Hi Ramesh -

I don't think the problem is clear:  We have a subclass of BaseDelegatingExecutionFactory called HarnessExecutionFactory.  The delegate execution factory supports inner joins by calling setSupportsInnerJoins(true) in its start() method. 

It appears there's a bug in the BaseDelegatingExecutionFactory:  it does not delegate supportsInnerJoins() to the delegate (probably because it is declared final in the BaseDelegatingExecutionFactory).  I think either this method should not be declared final or the BaseDelegatingExecutionFactory.setSupports*() methods should be called in the setDelegate() method.

[rareddy]

Mark,

Did you try overriding the "set"  methods like "setSupportsInnerJoins"? not the corresponding getter 'final' methods. Also, as work around you can always define a new @TranslatorProperty on your delegate, and when that method is called based on the configuration injection at the translator instantiation you can call any of the "set" methods.

One issue I do see is the delegate is being set after the "start" call, it should be done before the start call. So, may be you can override "setDelegate" method and call your setter methods as you suggesting. Since the different translator have different combinations of this supports, it would be difficult forr Teiid to call these in "setDelegate" method.

Also note that you do not have to extend the BaseDelegatingExecutionFactory, however you need to implement DelegatingExecutionFactory.

Ramesh..

[markaddleman]

I think we can get around the problem by requiring the delegate to call setSupports* in its constructor.  Then, in our execution factory's setDelegate, we copy the values from the delegate.

I do believe this is a bug in the BaseDelegatingExecutionFactory (which probably should be fixed in a similar way or remove "final" from the supports* methods and properly delegate).  If you agree, I can open a Jira ticket.

[shawkins]

Mark,

I agree.  Since you can independently configure the delegate via its own overrides, it does make sense to either have the BaseDelegatingExecutionFactory call the appropriate sets or remove the final restriction on the supports methods - note that final was originally added so that the setable translator properties would not mistakenly have their behavior overriden.  Go ahead and submit a JIRA.

Thanks,

Steve

[markaddleman]

Done:  TEIID-1983

[shawkins]

Revolved in 7.7.1.

Thanks,

Steve