[JBoss JIRA] (TEIID-2694) Support for Blob Input in Teiid REST services
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2694?page=com.atlassian.jira.plugin... ]
Steven Hawkins reopened TEIID-2694:
-----------------------------------
Assignee: Steven Hawkins (was: Ramesh Reddy)
blob parameters are not correctly recognized and instead an error results as a conversion from string is attempted:
TEIID30558 Error converting parameter number 1 with value "<root><p4>bar</p4></root>" of class java.lang.String to expected type blob.
at org.teiid.jboss.rest.TeiidRSProvider$2.write(TeiidRSProvider.java:102)
> Support for Blob Input in Teiid REST services
> ---------------------------------------------
>
> Key: TEIID-2694
> URL: https://issues.jboss.org/browse/TEIID-2694
> Project: Teiid
> Issue Type: Enhancement
> Affects Versions: 8.5
> Environment: EAP 6.1 Alpha , Teiid 8.5
> Reporter: Madhu Garimilla
> Assignee: Steven Hawkins
> Labels: Final
> Fix For: 8.10
>
>
> We are trying to upload large files as Blobs using Teiid REST service through VDB. Though we are writing the Blob objects to HttpUrlConnection object, it is not received on REST method. As per the conversation in the thread "https://community.jboss.org/thread/232840" Current parameter handling is done through strings and needs be enhanced to support Blob objects.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-4121) Enhancing the External Materialization
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4121?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-4121 at 4/13/16 11:24 PM:
--------------------------------------------------------------
I used to use the UNION
{code}
SELECT VDBName, SchemaName, Name, TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality FROM SYSADMIN.MatViews
UNION
SELECT VDBName, SchemaName, Name, TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality FROM status
UNION
SELECT VDBName, SchemaName, Name, TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality FROM status_1
....
{code}
This is more complexed, the Query result have duplicated items, this the reason I have filed TEIID-4131.
Thanks Steven, absolutely, your proposal are a better one.
was (Author: kylin):
I have use the UNION as below
{code}
SELECT VDBName, SchemaName, Name, TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality FROM SYSADMIN.MatViews
UNION
SELECT VDBName, SchemaName, Name, TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality FROM status
UNION
SELECT VDBName, SchemaName, Name, TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality FROM status_1
....
{code}
The Query result have duplicated items, this the reason I file TEIID-4131.
> Enhancing the External Materialization
> --------------------------------------
>
> Key: TEIID-4121
> URL: https://issues.jboss.org/browse/TEIID-4121
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Affects Versions: 9.x
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> The intention of move "status" table to physical database is to increase durable and fully control refresh and loading, but it increase the complexity.
> The "status" table by design should unique for whole VDB, if you look the https://teiid.gitbooks.io/documents/content/caching/External_Materializat..., the table structure:
> {code:sql}
> CREATE TABLE status
> (
> VDBName varchar(50) not null,
> VDBVersion integer not null,
> SchemaName varchar(50) not null,
> Name varchar(256) not null,
> TargetSchemaName varchar(50),
> TargetName varchar(256) not null,
> Valid boolean not null,
> LoadState varchar(25) not null,
> Cardinality long,
> Updated timestamp not null,
> LoadNumber long not null,
> PRIMARY KEY (VDBName, VDBVersion, SchemaName, Name)
> );
> {code}
> but currently, one VDB may have multiple "status" table, each view may have it's own "status" table. Further more, we can consider create status table automatically, which like internal, status create once VDB start, and configured in VDB scope.
> From finishedDeployment logic in MaterializationManager, MATERIALIZED_TABLE be used to determine whether the Mat is internal or external, But we lack the validation in metadata loading, in my previous test, the Internal Mat view configured lots of external view's properties like "status" table, the validation not throw excepton.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-4121) Enhancing the External Materialization
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4121?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4121:
------------------------------------
I have use the UNION as below
{code}
SELECT VDBName, SchemaName, Name, TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality FROM SYSADMIN.MatViews
UNION
SELECT VDBName, SchemaName, Name, TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality FROM status
UNION
SELECT VDBName, SchemaName, Name, TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality FROM status_1
....
{code}
The Query result have duplicated items, this the reason I file TEIID-4131.
> Enhancing the External Materialization
> --------------------------------------
>
> Key: TEIID-4121
> URL: https://issues.jboss.org/browse/TEIID-4121
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Affects Versions: 9.x
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> The intention of move "status" table to physical database is to increase durable and fully control refresh and loading, but it increase the complexity.
> The "status" table by design should unique for whole VDB, if you look the https://teiid.gitbooks.io/documents/content/caching/External_Materializat..., the table structure:
> {code:sql}
> CREATE TABLE status
> (
> VDBName varchar(50) not null,
> VDBVersion integer not null,
> SchemaName varchar(50) not null,
> Name varchar(256) not null,
> TargetSchemaName varchar(50),
> TargetName varchar(256) not null,
> Valid boolean not null,
> LoadState varchar(25) not null,
> Cardinality long,
> Updated timestamp not null,
> LoadNumber long not null,
> PRIMARY KEY (VDBName, VDBVersion, SchemaName, Name)
> );
> {code}
> but currently, one VDB may have multiple "status" table, each view may have it's own "status" table. Further more, we can consider create status table automatically, which like internal, status create once VDB start, and configured in VDB scope.
> From finishedDeployment logic in MaterializationManager, MATERIALIZED_TABLE be used to determine whether the Mat is internal or external, But we lack the validation in metadata loading, in my previous test, the Internal Mat view configured lots of external view's properties like "status" table, the validation not throw excepton.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months