[ https://jira.jboss.org/jira/browse/TEIID-817?page=com.atlassian.jira.plug... ] Work on TEIID-817 started by John Doyle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/TEIID-817?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIID-817: ------------------------------------ Is there a reason why the XML connector is handling the equality check it self rather than letting it handled by the engine by setting the "supportsCompareCriteriaEquals" to "true" in the XMLCapabilities class? Is it for pushdown? Then the above exception shouldn't be happening right? Can you please explain. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/TEIID-817?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIID-817: ------------------------------------ In WSDL based document models mapping may be necessary, where input and output documents defined. However this may not be possible in Schema based documents where no explicit input parameters defined unless a access pattern defined right? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/TEIID-817?page=com.atlassian.jira.plug... ] John Doyle commented on TEIID-817: ---------------------------------- Steve is right that the metadata on the response tables is not set to non-searchable. I could make that change in the importer and rely on the engine. Access patterns on the required parameters for a request are problematic. Many of the services I've encountered either don't have or correctly document the notion of 'required' parameters. I don't think there is a one size fits all solution in this area. I like the alternative suggested by Steve. One of the many drawbacks of the current approach is that the data and parts of the transport are in the model in the SOAP and HTTP cases, and more of the transport gets pulled up into the model as time passes due to customer requests. Separating these concerns would be an improvement. I've considered having a XML Source type connector that could feed a 'responseID' to the existing models and connector. Remove the transport from the current implementation, would be another way of saying this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira