February 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Updated: (TEIID-154) Add new connector property to allow bypass of logic that puts PROCs in transactions.

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-154?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIID-154: ------------------------------- Component/s: Connector API Query Engine Fix Version/s: 6.0.0 Affects Version/s: 6.0.0 > Add new connector property to allow bypass of logic that puts PROCs in transactions. > ------------------------------------------------------------------------------------ > > Key: TEIID-154 > URL: https://jira.jboss.org/jira/browse/TEIID-154 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Affects Versions: 6.0.0 > Reporter: Jerry Helbling > Assignee: Jerry Helbling > Fix For: 6.0.0 > > > Refer to internal case 192763. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-213) Improved logging for jgroups activity

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-213?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-213: --------------------------------- Component/s: Server still need to ensure that this gets documented > Improved logging for jgroups activity > ------------------------------------- > > Key: TEIID-213 > URL: https://jira.jboss.org/jira/browse/TEIID-213 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 6.0.0 > Reporter: Marc Shirley > Assignee: Ramesh Reddy > Fix For: 6.0.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > In the case of problems with jgroups/multicast, little information is recorded in the logs to help identify and resolve the cause of the communication problems. It would be useful to be able to turn on tracing for jgroups communication to track whether an issue is present. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-212) Allow for server discovery to be restricted to URL hosts

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-212?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-212: --------------------------------- Component/s: JDBC Driver > Allow for server discovery to be restricted to URL hosts > -------------------------------------------------------- > > Key: TEIID-212 > URL: https://jira.jboss.org/jira/browse/TEIID-212 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Driver > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Server discovery prior to 6.0 was forced to be based upon server lists from the server. While this works well in intranets, there are times when customers may want to explicitly control which hosts are used (for example if they are using a custom load-balancing solution). -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-216) Query timeout should be enforced by the server

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-216?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-216: --------------------------------- Component/s: Query Engine Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 Complexity: Medium > Query timeout should be enforced by the server > ---------------------------------------------- > > Key: TEIID-216 > URL: https://jira.jboss.org/jira/browse/TEIID-216 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #4990 : Query timeouts should be enforced by the server and client. > Also the RelationalNode nextbatch method will need to be made aware of the timeslice/timeout when handling 0 length batches. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-215) Create a less memory intensive implementation of the XML-Relational File connector.

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-215?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-215: --------------------------------- Component/s: XML Connector Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 > Create a less memory intensive implementation of the XML-Relational File connector. > ------------------------------------------------------------------------------------ > > Key: TEIID-215 > URL: https://jira.jboss.org/jira/browse/TEIID-215 > Project: Teiid > Issue Type: Feature Request > Components: XML Connector > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: John Doyle > Fix For: 6.1.0 > > > The XML-Relational file connector as currently implemented DOMs the XML document before parsing for results. Large files can exhaust the memory allocated to the server. We need an implementation that can handle arbitrarily large XML files. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-152) New SQL directive OPTION NOJOINPUSHDOWN that tells query planner to not push down any joins

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-152?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIID-152: ------------------------------- Component/s: Query Engine Fix Version/s: 6.x Affects Version/s: 6.x > New SQL directive OPTION NOJOINPUSHDOWN that tells query planner to not push down any joins > ------------------------------------------------------------------------------------------- > > Key: TEIID-152 > URL: https://jira.jboss.org/jira/browse/TEIID-152 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.x > Reporter: Greg Haber > Priority: Minor > Fix For: 6.x > > > This capability has been requested by a customer(see I-T ticket 217562). They want us to add in the following functionality: > -add an OPTION directive (OPTION NOJOINPUSHDOWN) to MetaMatrix SQL that tells the query planner whether or not to attempt to push down joins for a particular query. This would be a general purpose MetaMatrix SQL change. The default would be for our query planner to act as it does today (do join pushdown as allowed by connector capabilities), and the behavior if this OPTION directive was used would be to instead not do any join pushdown for any part of the user query, even if allowed by connector capabilities. > What this would allow them to do, if JBEDSP-348 is also implemented, is to leverage the limited join capability that SFDC has via its "relationship query" functionality. Because SFDC doesn't have full join capabilities, this would allow them to first try to submit a query against a VDB that uses SFDC as a source and see if the part of the join that the query planner pushes down to SFDC is something that SFDC can actually do. If not, the SFDC connector would throw an error, and the customer would resubmit their query with this OPTION NOJOINPUSHDOWN option. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-153) Support IS NULL criteria in the xml connector

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-153?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIID-153: ------------------------------- Component/s: XML Connector Fix Version/s: 6.x Affects Version/s: 6.x > Support IS NULL criteria in the xml connector > --------------------------------------------- > > Key: TEIID-153 > URL: https://jira.jboss.org/jira/browse/TEIID-153 > Project: Teiid > Issue Type: Feature Request > Components: XML Connector > Affects Versions: 6.x > Environment: 5.5.3GA Designer on Linux > Reporter: Greg Haber > Assignee: John Doyle > Priority: Minor > Fix For: 6.x > > Attachments: wsTest1_20081210_1.zip > > > If I try the query > select ResponseOut from "wsTest1"."SQS_DS.StockQuoteService.getPrice.getPriceMessage" where symbol IS NULL > against the VDB in the attached model project set, I get a message that the access pattern on symbol has not been satisfied. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-218) Security URL properties handling

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-218?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-218: --------------------------------- Component/s: JDBC Driver Server See also TEIID-249 > Security URL properties handling > -------------------------------- > > Key: TEIID-218 > URL: https://jira.jboss.org/jira/browse/TEIID-218 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Driver, Server > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #24196: Security URL properties are currently a mess in that there are three properties, clientToken, credentials, and trustedPayload that are all eventually treated at the trustedPayload. This is not desirable. Instead we should pass all of the connection properties to the membership service (as a map) for access by membership domains. This would remove the need to specifically pass the trustedPayload and application name as parameters. This could also be done for connectors provided that the message or the transport containing the connection properties is encrypted. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-218) Security URL properties handling

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-218?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-218: --------------------------------- Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 > Security URL properties handling > -------------------------------- > > Key: TEIID-218 > URL: https://jira.jboss.org/jira/browse/TEIID-218 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Driver, Server > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #24196: Security URL properties are currently a mess in that there are three properties, clientToken, credentials, and trustedPayload that are all eventually treated at the trustedPayload. This is not desirable. Instead we should pass all of the connection properties to the membership service (as a map) for access by membership domains. This would remove the need to specifically pass the trustedPayload and application name as parameters. This could also be done for connectors provided that the message or the transport containing the connection properties is encrypted. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-217?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-217: --------------------------------- Component/s: LDAP Connector Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 > LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result > ----------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-217 > URL: https://jira.jboss.org/jira/browse/TEIID-217 > Project: Teiid > Issue Type: Feature Request > Components: LDAP Connector > Affects Versions: 6.0.0 > Reporter: Michael Walker > Priority: Minor > Fix For: 6.1.0 > > > If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic. > A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN. > If we build an importer for LDAP, we should consider how to best handle this issue in the importer design. -- 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, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2009