[ https://issues.jboss.org/browse/TEIID-1589?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1589: ------------------------------------- The data looses it identity once it enters the view transformation process, I am not sure how preserving the metadata all way to the client is possible. This makes sense in muti-source scenario and on that Teiid does support a pseudo column "source_name" -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1589?page=com.atlassian.jira.plugin... ] Mark Addleman commented on TEIID-1589: -------------------------------------- I think it only makes sense to apply this at the column level since multiple translators are potential involved in a single result set. Further complicating this problem is that multiple translators could be involved on a row basis if we're talking about a UNION statement. I'm not sure how to address attaching metadata on a row-wise basis but an extension to the ResultSetMetadata interface to handle column-wise metadata would look something like: public Serializable getExecutionFactoryMetadata(String columnName); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1589?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1589: --------------------------------------- Just wanted to follow up. Taking this down to an individual row value level leads to a couple of observations: 1. you could treat it as a design time exercise, like Ramesh was alluding to, where there is an additional column added to your source tables and then it's up to your transformation logic to decide how that value is affected by join/set operations. 2. If this is a built in operation, it would be a significant amount of effort and introduce quite a lot of overhead. At the worst case, we would need a different metadata tracking value for each row value. Unless the size of the metadata were known the augmented batches would be significantly penalized for batch sizing and tier 1 caching. If this is the preferred path, I would probably opt for deferring this issue. 3. Depending on what the data values are, this feature is something akin to watermarking. Here again built-in support would be a large undertaking. But viewing the problem this way may provide you with a different approach, such as embedding the effect of the watermark in the data values themselves, which of course introduces complexity to any data manipulation and client interpretation of results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1589?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1589: --------------------------------------- If not a row/value level, there is an existing facility that you could use/abuse for this purpose. You can call ExecutionContext.addWarning and the exception will be delivered to the client as a SQLWarning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1589?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-1589. ----------------------------------- Resolution: Deferred Resolving as deferred. Source metadata per value would be a large undertaking and seemingly overlaps with watermarking concepts. And while having another method, such as ExecutionContext.addMetadata is a little cleaner (Serializable payload vs. Exception), the underlying functionality is essentially the same. Also SQLWarnings are delivered to the client without the need for a Teiid-specific metadata extension. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira