May 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Updated: (TEIID-103) Salesforce Connector: Count(*) did not appear to pushdown to SOQL.

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-103?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-103: --------------------------------- Issue Type: Feature Request (was: Bug) Fix Version/s: 6.1.0 (was: 6.x) Affects Version/s: 6.0.0 (was: 6.x) > Salesforce Connector: Count(*) did not appear to pushdown to SOQL. > ------------------------------------------------------------------ > > Key: TEIID-103 > URL: https://jira.jboss.org/jira/browse/TEIID-103 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: Steven Hawkins > Priority: Minor > Fix For: 6.1.0 > > > Count(*) did not appear to pushdown to SOQL. -- 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] Assigned: (TEIID-103) Salesforce Connector: Count(*) did not appear to pushdown to SOQL.

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-103?page=com.atlassian.jira.plug... ] Steven Hawkins reassigned TEIID-103: ------------------------------------ Assignee: Steven Hawkins (was: John Doyle) > Salesforce Connector: Count(*) did not appear to pushdown to SOQL. > ------------------------------------------------------------------ > > Key: TEIID-103 > URL: https://jira.jboss.org/jira/browse/TEIID-103 > Project: Teiid > Issue Type: Bug > Components: Salesforce Connector > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: Steven Hawkins > Priority: Minor > Fix For: 6.1.0 > > > Count(*) did not appear to pushdown to SOQL. -- 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] Created: (TEIID-546) Refresh on "deployment" tree item in results in blank screen

by Ramesh Reddy (JIRA)

Refresh on "deployment" tree item in results in blank screen ------------------------------------------------------------ Key: TEIID-546 URL: https://jira.jboss.org/jira/browse/TEIID-546 Project: Teiid Issue Type: Bug Components: Console Affects Versions: 6.0.0 Reporter: Ramesh Reddy Fix For: 6.1.0 In the Console, if you try to "refresh" while on the "Deployment" tree item, it will result in blank screen in right hand side -- 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
2
0 / 0

[JBoss JIRA] Resolved: (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... ] Ramesh Reddy resolved TEIID-233. -------------------------------- Resolution: Done These two properties are combined into one cluster.use_multicast=false cluster.protocol=TCP to cluster.protocol=UNICAST_TCP|UNICAST_UDP|MULTICAST Also, when the cluster node is added, the "unicast.members" property is automatically updated to contain the primary server's cluster information, however the primary server needs to be manually updated with the newly added server information in its "teiid.properties" file. > 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

[JBoss JIRA] Created: (TEIID-549) Connectorclasspath.xml file in Teiid depoy directory contains "extension:" instead of "extensionjar:" prefix for various dependencies. Connectors fail to start.

by Ken Johnson (JIRA)

Connectorclasspath.xml file in Teiid depoy directory contains "extension:" instead of "extensionjar:" prefix for various dependencies. Connectors fail to start. ----------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: TEIID-549 URL: https://jira.jboss.org/jira/browse/TEIID-549 Project: Teiid Issue Type: Bug Affects Versions: 6.0.0 Environment: Teiid 6.0.0 Embedded on RHEL 5.3 w/OpenJDK 1.6. Reporter: Ken Johnson Assignee: Steven Hawkins For various connectors defined in connectorclasspath.xml, many of the jars fulfilling external dependencies are prefixed incorrectly with "extension:" rather than "extensionjar:". This causes those connectors to fail on startup. For example, see the following excerpt for the Salesforce.com connector: DefaultValue="extensionjar:connector_patch.jar;extensionjar:connector-salesforce.6.0.0.jar;extension:commons-codec-1.2.jar;extension:commons-discovery-0.2.jar;extension:commons-httpclient-3.0.1.jar;extension:xmlsec-1.3.0.jar;extension:axis-1.3.jar;extension:axis-jaxrpc-1.3.jar;extension:axis-saaj-1.2.jar;extension:axis-schema-1.3.jar;extension:commons-discovery-0.2.jar;extension:commons-logging-1.1.jar;extension:jms-1.1.jar;extension:servlet-api-2.5.jar;extension:jaxen-1.1.1.jar;extension:jdom-1.0.jar;extension:log4j-1.2.8.jar;extension:opensaml-1.1b.jar;extension:salesforce-api-6.0.0.jar;extension:wsdl4j-1.5.1.jar;extension:wss4j-1.5.0.jar;extension:xalan-2.7.0.jar;extension:xml-apis-1.0.b2.jar" The XML Connector is also impacted. -- 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

2
5
0 / 0

[JBoss JIRA] Created: (TEIID-550) Connector passwords encrypted by Teiid Designer are not properly decrypted by Teiid standalone runtime.

by Ken Johnson (JIRA)

Connector passwords encrypted by Teiid Designer are not properly decrypted by Teiid standalone runtime. --------------------------------------------------------------------------------------------------------- Key: TEIID-550 URL: https://jira.jboss.org/jira/browse/TEIID-550 Project: Teiid Issue Type: Bug Affects Versions: 6.0.0 Environment: Teiid 6.0.0, JBoss AS 4.2.3, Sun JDK 1.6.0. Reporter: Ken Johnson Assignee: Steven Hawkins Using Teiid Designer snapshot from 4/30, create VDB with connectors bound to local MySQL using explicit username and password. Execution in Designer works correctly. Deploy VDB to Teiid configured with File Path profile on JB AS 4.2.3. Upon Teiid startup, the MySQL connector bindings fail due to bad password. It does correctly use the MySQL username from the connector binding but the correct password is not being submitted. To workaround, I edited ConfigurationInfo.def in the VDB archive file to remove the encrypted password and replace with hardcoded clear-text password. Then the bindings were able to start correctly. Do Teiid Designer and Teiid share the same keystore? If not, what is the procedure for enabling password decryption at runtime? -- 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

3
4
0 / 0

[JBoss JIRA] Resolved: (TEIID-428) System Property Changes - Not showing up in Audit Log and System Log has entry but doesn't state what property was changed

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-428?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-428. ---------------------------------- Resolution: Done added full auditing to the xmlactionupdatestrategy > System Property Changes - Not showing up in Audit Log and System Log has entry but doesn't state what property was changed > -------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-428 > URL: https://jira.jboss.org/jira/browse/TEIID-428 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 6.0.0 > Environment: Windows client running against Windows server > Reporter: Warren Gibson > Assignee: Steven Hawkins > Priority: Optional > Fix For: 6.1.0 > > Attachments: log.rtf > > > I changed 4 System Properties and found no entries in the Audit log but entries did show up in the System Log. However the entries in the System log does not specify which property was changed. Changes to System Properties should show up in Audit Log. This is one example. See attachment for other examples: > My action - Encryption - Unchecked Client Side Password. > Log: > Mar 06, 2009 14:07:47.500 [SocketWorkerQueue_Worker_52|0] ERROR <AUDIT_ADMIN|0> Administrator [ssmith@NewLDAP], session [7512] requesting access which requires role [Admin.SystemAdmin] to method [ConfigurationAdminAPIImpl.executeTransaction([Set ConfigurationID Next Startup; new value = false, previous value = true])]. > Mar 06, 2009 14:07:47.500 [SocketWorkerQueue_Worker_52|0] ERROR <AUDIT_ADMIN|0> Administrator [ssmith@NewLDAP], session [7512] granted access to method [ConfigurationAdminAPIImpl.executeTransaction([Set ConfigurationID Next Startup; new value = false, previous value = true])]. > Mar 06, 2009 14:07:47.515 [SocketWorkerQueue_Worker_52|0] INFO <CONFIG|0> Completed execution of actions. > Mar 06, 2009 14:07:47.546 [SocketWorkerQueue_Worker_52|0] INFO <CONFIG|0> Configuration Next Startup document written successfully to stream. -- 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] Created: (TEIID-440) Capture the vendor SQLSTATE code, if the connector connection fails

by Ramesh Reddy (JIRA)

Capture the vendor SQLSTATE code, if the connector connection fails ------------------------------------------------------------------- Key: TEIID-440 URL: https://jira.jboss.org/jira/browse/TEIID-440 Project: Teiid Issue Type: Feature Request Components: Misc. Connectors Affects Versions: 6.0.0 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Priority: Trivial Fix For: 6.1.0 Currently when the JDBC connector fails to make the connection, we correctly unroll the SQLException, but do not provide the SQLSTATE code on to the wrapping exception's description, so that it is visible in the Teiid's logs. -- 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
2
0 / 0

[JBoss JIRA] Commented: (TEIID-244) Salesforce Connector should offer the abilty to query about object deletions.

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-244?page=com.atlassian.jira.plug... ] John Doyle commented on TEIID-244: ---------------------------------- Checked in queryAll for the connector portion. > Salesforce Connector should offer the abilty to query about object deletions. > ----------------------------------------------------------------------------- > > Key: TEIID-244 > URL: https://jira.jboss.org/jira/browse/TEIID-244 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: John Doyle > Fix For: 6.1.0 > > > Genentech wants to materialize lots of SalesForce data in Oracle, to speed up their reporting query times. It makes a significant difference because SFDC does not support joins, whereas Oracle does. Wanting the best of both worlds, they also want the data to be as fresh as possible -- ideally, the mat views would be no more than 10 minutes out-of-sync with the live data. > The amount of data in SalesForce already takes 20+ minutes to cache, and it will slowly grow over time. So, the current materialization process will not meet the cache coherence (freshness) requirement, since the data will be stale by the time the staging table is populated and swapped in. > How would you speed it up? > .......response.... > I actually put together a custom materialization script > (attached,with doc and sample config file) for Credit Suisse for doing > these sorts of partial refreshes. It is Oracle-specific, but since > that is what you are doing too it should work for you too. > However, the use case at Credit Suisse was for doing these partial > refreshes nightly, with full refreshes done weekly. There is (just as > with our standard materialization scripts) a short period (when the > table names are being swapped) when the materialization won't be stable > (queries could fail or return unexpected results). I don't know if > that makes it not suitable for doing 10 minute refreshes. > I would recommend instead using the materialization only for historical > data (from overnight materialization run), and unioning it to the live > data for the newer stuff. That is, query SFDC only for data where > createdDate or LastModifiedDate = today, and union that with the > current data. Two issues you'd need to deal with in your logic: > -if the same record is retrieved from both sources (meaning it was an > existing record that had been modified today), the historical record > should be discarded in favor of the live one. > -deleted records - how to detect records that were deleted today? If > you could ask SFDC exactly what was deleted today that would be great, > but that is probably wishful thinking. So failing that you would need > to ask SFDC for the keys for all live records, and then discard from > the historical data any records with keys not on that list. Or, you > could just live with having the deleted records in the view for an > extra day... -- 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 Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-203?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIID-203: -------------------------------------- After some initial work here's a possible set of capabilities changes (which include simplifications that could fall under TEIID-529): replace supportsAggregates with supportsGroupBy and supportsHaving. Individual aggregate support would still be conveyed by supportsAggregateXXX remove supportsCompareCriteria - it's redundant with the individual compares remove supportsCompareCriteriaNotEquals - it's implied by supportsNotCriteria and supportsCompareCriteriaEquals replace all supportsCompareGreater/Less... with a single supportsCompareCriteriaOrdered replace supportsJoins with supportsInnerJoins remove supportsQuantifiedCompareCriteria - it's redundant with the individual quantified supports remove supportsScalarFunctions - it's redundant with the supported funcitons list replace supportsSelectLiteral with supportsSelectExpression - which covers the ability to project anything other than an element remove supportsAndCriteria - not used and little chance of it being used add getSupportedJoinCriteria that returns an enum SupportedJoinCriteria that can be one of {ANY, THETA, EQUI, KEY} > 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2009