April 2012 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-1820) like_regex only matches full string patterns

by Steven Hawkins (Created) (JIRA)

like_regex only matches full string patterns -------------------------------------------- Key: TEIID-1820 URL: https://issues.jboss.org/browse/TEIID-1820 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.5 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.6 like_regex currently asks the compiled pattern matcher if the pattern matches in full, not for the first occurrence. This means that a pattern such as 'a' will not match 'cat'. -- 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

12 years

5
6
0 / 0

[JBoss JIRA] (TEIID-1834) Add suppot for a comparable binary type

by Steven Hawkins (Created) (JIRA)

Add suppot for a comparable binary type --------------------------------------- Key: TEIID-1834 URL: https://issues.jboss.org/browse/TEIID-1834 Project: Teiid Issue Type: Feature Request Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.0 Teiid currently lacks a binary/varbinary type. Since we have both blob/clob, it would be natural to also introduce a varbinary analog to string. It would be a comparable type and need an escape syntax for entering literals. Translators would need to be modified to account for binary literals. See the forum post for current workarounds. We also as a one off have previously allowed clob types to be comparable, see also TEIID-1248. Another approach would by to allow clob/blob to comparable in Teiid, but possibly not at the source as per the searchability metadata. We would still need to support an escape syntax and modify translators to use native type information and the appropriate literal format. The advantage of this latter approach is that there is nothing more that designer must do to support this case. The most practical benefit from introducing a varbinary type would be in having a better size estimate (it would be limited to 8000 bytes) for buffering. -- 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

12 years

3
6
0 / 0

[JBoss JIRA] (TEIID-1901) Redo Quick Start guide for Teiid 8.0 changes

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-1901: ----------------------------------- Summary: Redo Quick Start guide for Teiid 8.0 changes Key: TEIID-1901 URL: https://issues.jboss.org/browse/TEIID-1901 Project: Teiid Issue Type: Task Components: Documentation Reporter: Ramesh Reddy Fix For: 8.0 Currently the Quick start document for 8.0 still shows the techniques used with the Teiid 7 as per data creation deployment etc. This needs be revised for 8.0 -- 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

12 years

2
2
0 / 0

[JBoss JIRA] (TEIID-1879) Teradata Query Testing - Unhandled exception causing SOCKET CLOSED condition

by Warren Gibson (Created) (JIRA)

Teradata Query Testing - Unhandled exception causing SOCKET CLOSED condition ---------------------------------------------------------------------------- Key: TEIID-1879 URL: https://issues.jboss.org/browse/TEIID-1879 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.6 Reporter: Warren Gibson Assignee: Steven Hawkins Attachments: Teradata_log_vqt Testing Teradata as a source with Teiid 7.6 produces a SOCKET CLOSED condition on the below query and all VQT queries following it. SELECT * FROM VQT.Mapping1 ORDER BY IntKey There is an unhandled exception in the attached log. -- 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

12 years

4
3
0 / 0

[JBoss JIRA] (TEIID-1867) Duplicate metadata for multisource models

by Andriy Rokhmanov (Created) (JIRA)

Duplicate metadata for multisource models ----------------------------------------- Key: TEIID-1867 URL: https://issues.jboss.org/browse/TEIID-1867 Project: Teiid Issue Type: Bug Affects Versions: 7.5 Environment: Windows 7, JBoss 5.1.0, java version 1.6.0_22 - 64 bit. Reporter: Andriy Rokhmanov Assignee: Steven Hawkins Attachments: chorus-vdb.xml When more than one multi-source model defined in single VDB, the tables from one multi-source schema appear in the another one. See screenshot and sample vdb attached. The issue reproducible on our side with file, h2 and hsqldb multi-source models. We have to define only one multi-source model per vdb to avoid the problem. -- 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

12 years

6
9
0 / 0

[JBoss JIRA] (TEIID-1922) BaseDelegateTranslator's start method is being called before the delegate execution factory is set.

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-1922: ----------------------------------- Summary: BaseDelegateTranslator's start method is being called before the delegate execution factory is set. Key: TEIID-1922 URL: https://issues.jboss.org/browse/TEIID-1922 Project: Teiid Issue Type: Bug Components: Misc. Connectors Affects Versions: 7.4 Reporter: Ramesh Reddy Assignee: Steven Hawkins Priority: Minor Fix For: 7.7 BaseDelegatingTranslator's start method is called before the setDeletegate is called to set the delegate name. -- 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

12 years

2
2
0 / 0

[JBoss JIRA] (TEIID-1872) Implicit temp table creation fails with insert and explicit columns

by Steven Hawkins (Created) (JIRA)

Implicit temp table creation fails with insert and explicit columns ------------------------------------------------------------------- Key: TEIID-1872 URL: https://issues.jboss.org/browse/TEIID-1872 Project: Teiid Issue Type: Bug Components: Embedded Affects Versions: 7.6 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.6.1, 8.0 using something like: insert into #x (y,z) select ... will fail since we are defining #x using the query expression. -- 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

12 years

3
2
0 / 0

[JBoss JIRA] (TEIID-1927) BLOB/CLOB errors while using teiid 7.6 JDBC

by Graeme Gillies (JIRA)

Graeme Gillies created TEIID-1927: ------------------------------------- Summary: BLOB/CLOB errors while using teiid 7.6 JDBC Key: TEIID-1927 URL: https://issues.jboss.org/browse/TEIID-1927 Project: Teiid Issue Type: Bug Affects Versions: 7.6 Environment: java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.10) (rhel-1.23.1.9.10.el5_7-x86_64) OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) Running on RHEL 5, teiid 7.6 inside of JBoss EAP 5.1.1 Client is SQuirrel SQL client version 3.2.2 or DBVisualiser version FREE 8.0.7 Reporter: Graeme Gillies Assignee: Steven Hawkins Hi, We have recently upgraded to teiid 7.6 on our environment, and we have noticed that a few users have been reporting problems querying data via JDBC surrounding blobs/clobs. The fields in the VDB model are marked as MEDIUMTEXT, but when trying to run an example query such as {noformat} select bug_id, keywords from bugzilla.bugs order by bug_id limit 1000; {noformat} In squirrel you just get the values back as <Clob> (not the real value) and in dbvisualiser you get back CLOB in the field with the following errors {noformat} [cleared] ting clob data: 08:53:42 [ERROR Thread-22 TextData.getData] javax.sql.rowset.serial.SerialException: Invalid position in BLOB object set 08:53:42 [ERROR Thread-22 TextData.getData] Error getting clob data: 08:53:42 [ERROR Thread-22 TextData.getData] javax.sql.rowset.serial.SerialException: Invalid position in BLOB object set 08:53:42 [ERROR Thread-22 TextData.getData] Error getting clob data: 08:53:42 [ERROR Thread-22 TextData.getData] javax.sql.rowset.serial.SerialException: Invalid position in BLOB object set 08:53:42 [ERROR Thread-22 TextData.getData] Error getting clob data: 08:53:42 [ERROR Thread-22 TextData.getData] javax.sql.rowset.serial.SerialException: Invalid position in BLOB object set 08:53:42 [ERROR Thread-22 TextData.getData] Error getting clob data: 08:53:42 [ERROR Thread-22 TextData.getData] javax.sql.rowset.serial.SerialException: Invalid position in BLOB object set 08:53:42 [ERROR Thread-22 TextData.getData] Error getting clob data: {noformat} Another query giving us grief is {noformat} SELECT p.plan_id, p.product_id, p.author_id, p.type_id, v.id as default_product_version, p.name, p.creation_date, p.isactive, p.extra_link, p.parent_id FROM testopia.test_plans p left join testopia.versions v on p.product_id = v.product_id and p.default_product_version = v.value where p.creation_date>= '2012-02-05' {noformat} which gives the error {noformat} ERROR: Expressions of type OBJECT, CLOB, BLOB, or XML cannot be used in comparison: p.default_product_version = v."value". DETAIL: org.teiid.jdbc.TeiidSQLException: Expressions of type OBJECT, CLOB, BLOB, or XML cannot be used in comparison: p.default_product_version = v."value". {noformat} We updated our VDB models using teiid designer 7.6 at the same time we updated teiid to 7.6, so it could be something we have changed there. Have we got the wrong type set for these fields (should they not be MEDIUMTEXT) or is this a bug in the driver or in teiid? Regards, Graeme -- 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

12 years

2
10
0 / 0

[JBoss JIRA] (TEIID-1838) Change to source model connection through AdminApi using assignToModel() does not reflect in jdbc queries to that source model

by Ramesh Reddy (Created) (JIRA)

Change to source model connection through AdminApi using assignToModel() does not reflect in jdbc queries to that source model ------------------------------------------------------------------------------------------------------------------------------ Key: TEIID-1838 URL: https://issues.jboss.org/browse/TEIID-1838 Project: Teiid Issue Type: Bug Components: AdminApi Affects Versions: 7.5 Environment: Windows server 2008 R2, JBoss 5.1 Reporter: Farrukh Ihtisham Assignee: Ramesh Reddy Fix For: 7.6 When source model's connection is changed using following adminapi code; AdminFactory adminFactory = AdminFactory.getInstance(); Admin admin = adminFactory.createAdmin("admin", "admin".toCharArray(), "mms://localhost:31443"); admin.assignToModel("Sample", 1, "SQLSourceA", "SQLSourceA", "sqlserver", "SQLSourceA_2"); Any jdbc query result would still be from the old data source. However when verified using following adminapi code; VDB vdb = admin.getVDB("sample", 1); Model m = vdb.getModel("SQLSourceA"); String jndiName = m.getSourceConnectionJndiName("SQLSourceA"); The jndiName shows that the connection is successfully updated. -- 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

12 years

4
3
0 / 0

[JBoss JIRA] (TEIID-1837) Replication should distribute load off of the coordinator

by Steven Hawkins (Created) (JIRA)

Replication should distribute load off of the coordinator --------------------------------------------------------- Key: TEIID-1837 URL: https://issues.jboss.org/browse/TEIID-1837 Project: Teiid Issue Type: Quality Risk Components: Server Affects Versions: 7.6 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.0 Initial and partial state pull transfers (the latter is only in 8.0+) both just utilize the coordinator. It would be better to add issue a polling query across the cluster "hasState(blah)" and then select the member to pull from which gives the first positive response. -- 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

12 years

4
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues April 2012