April 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-527) Ensure that the original command is not modified by rewrite or planning

by Steven Hawkins (JIRA)

Ensure that the original command is not modified by rewrite or planning ----------------------------------------------------------------------- Key: TEIID-527 URL: https://jira.jboss.org/jira/browse/TEIID-527 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 6.1.0 The original command maintained by the request is not a full clone deep language object changes during rewrite or planning will cause it to be modified. This is undesirable for later checks, such are for metadata. -- 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

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Commented: (TEIID-124) insert with query should be supported at the connector level

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-124?page=com.atlassian.jira.plug... ] John Doyle commented on TEIID-124: ---------------------------------- Sounds good to me. > insert with query should be supported at the connector level > ------------------------------------------------------------ > > Key: TEIID-124 > URL: https://jira.jboss.org/jira/browse/TEIID-124 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #25005: Insert into with a query is now supported at the query level and is the ANSI standard way of representing select into. Insert with a query should become the dominant concept rather than select into, and it should be supported through the connector layer so that same source operations do not have the overhead of a select into. -- 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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-105) MySQL capabilities should be made specific to version 4/5

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-105?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIID-105: -------------------------------------- How we present this from a gui perspective is a different concern. It would be nice if such a display were hierarchical when multiple versions of a database are supported, but what we're describing here is having specific translation logic for version 4 and 5 of mysql. > MySQL capabilities should be made specific to version 4/5 > --------------------------------------------------------- > > Key: TEIID-105 > URL: https://jira.jboss.org/jira/browse/TEIID-105 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 6.x > Reporter: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #24746: The current mysql capabilities seem to have been written for version 5 (it initially included support for timestampdiff). The support for 4.x should be specifically refined or specifically removed from the docs. 4.x goes completely eol by the end of 2009, so it's unlikely many customers would care if this were done for 5.5.1. > see also http://www.mysql.com/company/legal/lifecycle/#calendar -- 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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-124) insert with query should be supported at the connector level

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-124?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIID-124: -------------------------------------- This is just a different varient of insert support. For example we use the table metadata to determine basic support and we currently have a capability to indicate bulk insert support. There would be an additional capability supportsInsertQueryExpression, when true we would allow the push of queries in the form of "insert into table <query expression>", such that the query expression is pushable and the table is a valid insert target. If the capability is not supported we would degrade to our normal handling that will first check for bulk insert, then batched update, then a single insert at a time. > insert with query should be supported at the connector level > ------------------------------------------------------------ > > Key: TEIID-124 > URL: https://jira.jboss.org/jira/browse/TEIID-124 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #25005: Insert into with a query is now supported at the query level and is the ANSI standard way of representing select into. Insert with a query should become the dominant concept rather than select into, and it should be supported through the connector layer so that same source operations do not have the overhead of a select into. -- 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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-105) MySQL capabilities should be made specific to version 4/5

by Larry O'Leary (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-105?page=com.atlassian.jira.plug... ] Larry O'Leary commented on TEIID-105: ------------------------------------- Is it not an option to have the translators support both 4 and 5? Seems ideal to have a single connector support multiple versions of the same source rather than introducing a big list of connectors with minor differences. Just a thought. > MySQL capabilities should be made specific to version 4/5 > --------------------------------------------------------- > > Key: TEIID-105 > URL: https://jira.jboss.org/jira/browse/TEIID-105 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 6.x > Reporter: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #24746: The current mysql capabilities seem to have been written for version 5 (it initially included support for timestampdiff). The support for 4.x should be specifically refined or specifically removed from the docs. 4.x goes completely eol by the end of 2009, so it's unlikely many customers would care if this were done for 5.5.1. > see also http://www.mysql.com/company/legal/lifecycle/#calendar -- 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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-203) Make connector capabilites more granular.

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-203?page=com.atlassian.jira.plug... ] John Doyle commented on TEIID-203: ---------------------------------- Both the reference type and the multi-select picklist are Strings. The multi-select is a semicolon separated string of values. The reference is a primary key to another object. Salesforce will throw a "malformed query" if we use "Order By" on a text area or a multi-select picklist. IN is not allowed for the multi-select, only = and != as well as the two functions we provide to implement the includes and excludes functions. > Make connector capabilites more granular. > ----------------------------------------- > > Key: TEIID-203 > URL: https://jira.jboss.org/jira/browse/TEIID-203 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Some connector capabilites are only available in combination with others. For example, if you wish to support the SupportsAggregatesCount capability, you have to also support the SupportsAggregates capability(GROUP BY and HAVING). This requirement creates additional requirements for a connector where the source syustem cabilities do not correspond with the relationships we have defined between capabilites. > For instance, the SQL supported by salesforce can include the count(*) function, but it does not support GROUP BY or HAVING. Because we require c connector to support SupportsAggregates befrore it can support count(*), the connector is required to implement those functions if it wishes to pus down count(*). -- 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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-124) insert with query should be supported at the connector level

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-124?page=com.atlassian.jira.plug... ] John Doyle commented on TEIID-124: ---------------------------------- Can you explain what kind of connector capabilities will be available to effect how this gets to the connector? For instance, even though this isn't a join would a connector not supporting joins get two invocations, the Select and the Insert? > insert with query should be supported at the connector level > ------------------------------------------------------------ > > Key: TEIID-124 > URL: https://jira.jboss.org/jira/browse/TEIID-124 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #25005: Insert into with a query is now supported at the query level and is the ANSI standard way of representing select into. Insert with a query should become the dominant concept rather than select into, and it should be supported through the connector layer so that same source operations do not have the overhead of a select into. -- 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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-55) Salesforce connector doesn't expose standard connection pooling or caching connector properties

by Tim Walsh (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-55?page=com.atlassian.jira.plugi... ] Tim Walsh resolved TEIID-55. ---------------------------- Resolution: Done added elements to teiid/connector-salesforce/src/main/resources/connector-salesforce.xml for pooling and cache > Salesforce connector doesn't expose standard connection pooling or caching connector properties > ----------------------------------------------------------------------------------------------- > > Key: TEIID-55 > URL: https://jira.jboss.org/jira/browse/TEIID-55 > Project: Teiid > Issue Type: Bug > Components: Salesforce Connector > Affects Versions: 6.x > Environment: SFDC Connector 5.5 GA; MM Designer 5.5.2 0037 Linux > Reporter: Greg Haber > Assignee: Tim Walsh > Fix For: 6.x > > > The connector framework provides both caching and pooling support for connectors that implement the required interfaces. The SFDC connector code does indeed implement all of these interfaces. > In order to allow users to fine tune caching or pooling behavior for a connector binding, the connector type's CDK file must also list all of the standard connector framework caching and pooling properties. The SFDC connector does not currently expose these properties. > The SFDC connector's CDK file should be updated to include these properties. Unfortunately we don't document in the connector developer's guide what properties should be defined, but this info can be found in the definition of any of the standard JDBC connector types (Oracle ANSI, etc). These can be marked as "advanced" properties for SFDC as they are for the JDBC connector types. > The max pooled connections per user property is especially important for SFDC, because of the hard limit on 5 concurrent server side cursors per user in SFDC. -- 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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-96) Salesforce connector isn't consistently protecting against null values in binding parameters

by Tim Walsh (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-96?page=com.atlassian.jira.plugi... ] Tim Walsh resolved TEIID-96. ---------------------------- Resolution: Done Added null test to /teiid/connectors/connector-salesforce/src/main/java/com/metamatrix/connector/salesforce/Connector.java > Salesforce connector isn't consistently protecting against null values in binding parameters > -------------------------------------------------------------------------------------------- > > Key: TEIID-96 > URL: https://jira.jboss.org/jira/browse/TEIID-96 > Project: Teiid > Issue Type: Bug > Components: Salesforce Connector > Affects Versions: 6.x > Environment: 5.5.2 with patch 0050; Salesforce connector with patch p552_080717_0001 > Reporter: Greg Haber > Assignee: Tim Walsh > Priority: Minor > Fix For: 6.x > > > The GA release of the SFDC connector had one binding parameter that should have a number value - InLimit. The p552_080717_0001 patch adds a second - PingInterval. > When these parameters are actually read by the connector in com.metamatrix.connector.salesforce.connection.SalesforceConnection, the connector tries to use Integer.decode or Long.decode to convert these values to the correct numeric type from the String that is returned by the Properties object. There is no checking to see if the values here are null before calling the decode method, so the connector bombs out with an NPE if either value is null. > We should either silently fall back on a default value or throw an appropriate ConnectorException if these values are null, but we shouldn't be throwing an NPE. > I looked through the code and it looks like we are careful with checking for nulls for the other SFDC connector binding parameters. > Also, I noticed that both of these parameters are defined in the connector binding type's CDK file as type String, instead of the correct numeric type. I don't know if setting the type correctly in the CDK file would actually add some extra validation in this case, but we should set the types correctly here in case we do (or if we don't, to take advantage of such validation if we add it in a later release). Using correct numeric types would also make this connector type definition consistent with the other standard MMx connectors, where these types are widely used. -- 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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Work started: (TEIID-233) Server should support JGroups communication over P2P

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-233?page=com.atlassian.jira.plug... ] Work on TEIID-233 started by Ramesh Reddy. > Server should support JGroups communication over P2P > ---------------------------------------------------- > > Key: TEIID-233 > URL: https://jira.jboss.org/jira/browse/TEIID-233 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 6.0.0 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 6.1.0 > > > Currently Server only supports the JGroups over Multicast we need to support unicast protocol tool, with configuration. -- 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

15 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues April 2009