[ https://issues.jboss.org/browse/TEIID-2285?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2285: ------------------------------------- You can already define metadata on a loopback, for that matter on any translator. You can even use native from source combined with below {code} <model name="MarketData"> <source name="text-connector" translator-name="loopback" /> <metadata type="DDL"><![CDATA[ CREATE FOREIGN TABLE G1 (e1 string, e2 integer); ]]> </metadata> </model> {code} As per the distinct data, we can make little more random for each row, but anything more we may be better off using a real db. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2285?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2285: ---------------------------------- Issue Type: Enhancement (was: Feature Request) Fix Version/s: Open To Community Priority: Minor (was: Major) 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2285?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2285: --------------------------------------- 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. 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. 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2285?page=com.atlassian.jira.plugin... ] Filip Nguyen edited comment on TEIID-2285 at 11/12/12 1:31 PM: --------------------------------------------------------------- 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). was (Author: fnguyen): 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 capability to the pull request (extending loopback from BaseDelegatingExecutionFactory and adding some logic so that Loopback is still backwards compatible without "delegate" property set). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2285?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2285. ----------------------------------- Resolution: Done merged the pull with some minor changes. Will look at updating the loopback for end user usability as a separate issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira