No, that is only to set the default behavior of all capabilities, which is the TeiidExecutionFactory. Otherwise the delegate will be set at runtime via injection.

Does it need dependencies added to all the other translators in the its module.xml file, so that it can delegate correctly?

switched to a delegation mode the remove the need for the disable capabilities property (which was not yet documented). By default loopback mimics a teiid translator, but can be set to jdbc-simple (to disable capabilities) or any other translator to mimic it's planning.

Will treat adding HardCodedExecutionFactory behavior as another issue.

Switching the translator over to a delegation model.

merged the pull with some minor changes. Will look at updating the loopback for end user usability as a separate issue.

Will pull into 8.3.

There is the pull request: https://github.com/teiid/teiid/pull/23

The proposed documentation was added to the Confluence.

If you don't think it is good for the project we will give it to perf. QA team as a custom transalator.

OTH if you think it is ok you do not have to immediately close the pull request. I can add the delegating behavior of the translator to the pull request (extending loopback from BaseDelegatingExecutionFactory and adding some logic so that Loopback is still backwards compatible without "delegate" property set).

> To have hard coded data is not a good solution too, because you would need them to be stored in memory, which would influence the test.

That is an implementation choice. You could just as easily backend into a caching system after loading the results from files (see also Van's byteman based results replacement tool). Using hard-coded results can also just be an override aspect, for example our internal HardCodedDataManager can optionally return a dummy row if there is no data supplied for the give command.

> Also it is needed to disable some capabilites of loopback translator so that teiid engine can perform comparing, joining, filtering etc. of data generated by the translator.

Ideally that would be based upon allowing the translator to act as a delegating translator - to mimic another built-in translator - and/or with additional settable properties - rather than just hardcoding to disabled. I don't see changes along these lines in the pull request.

> Please, look at the modified translator and if you like it we can create pull request.

As an incremental change to the current loopback, it would be fine to add these additional properties. For some distinct/join scenarios this would allow for simple testing. Although with capabilities disabled, you may also want to consider modifications such as looking at the table/column metadata to better mimic the situation without requiring separately configured translators.

I have discussed this with Pavel Macik (he will execute performance tests) and he prefers loopback translator with few changes. H2 database causes to much overhead. To have hard coded data is not a good solution too, because you would need them to be stored in memory, which would influence the test. (Pavel will perform tests on 100000 distinct rows.)

So Filip has modified loopback translator. He added two more properties to it:
IncrementRows - If it is enabled it will increment values in all columns. It works for all datatypes. Values in each row are predicable.
CharacterValuesSize - Defines length of string, varchar etc.

Also it is needed to disable some capabilites of loopback translator so that teiid engine can perform comparing, joining, filtering etc. of data generated by the translator.

We thing that these changes can be used in project. Please, look at the modified translator and if you like it we can create pull request. Thanks.

Here is the repository with modified loopback translator: https://github.com/nguyenfilip/teiid-1
branch: loopback-2285

Loopback is good a performance testing row through-put (which used to comprise a fair amount of the performance tests). As you and Van point out, it is not ideal for a Teiid query plan of anything more complicated than a simple query.

There is a balance to be struck through between putting too much effort into this and just using a low-overhead in-memory database, such as h2.

If anything I would advocate refining loopback into a delegating translator (so that it can proxy the actual instances to report back the proper capabilities) and also allow it to have hard coded results - see the test class org.teiid.jdbc.HardCodededExecutionFactory. For targeted testing with a limited set of possible queries/results, that would be far less work than developing more logic to effectively generate a database.