[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, 7 months
[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, 7 months
[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, 7 months