[JBoss JIRA] (TEIID-4205) send results proactively under a cursor as it looks like the ODBC client requires a transaction.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4205?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4205.
-----------------------------------
Fix Version/s: 9.0
Resolution: Done
Added the system property org.teiid.honorDeclareFetchTxn with the default of false to control whether we honor the transaction that is started for a cursor and tested with the pgsqlodbc client to ensure that it gracefully accepts this.
Do we want this in 8.12.5 as well?
> send results proactively under a cursor as it looks like the ODBC client requires a transaction.
> ------------------------------------------------------------------------------------------------
>
> Key: TEIID-4205
> URL: https://issues.jboss.org/browse/TEIID-4205
> Project: Teiid
> Issue Type: Feature Request
> Components: ODBC, Server
> Affects Versions: 8.7.5.6_2
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> Currently when querying large resultsets with ODBC the results are not sent as soon as the batch is logically available (like we do for JDBC)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-4204) Examples dynamicvdb-restservice - rest client returns always empty body
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4204?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4204.
-----------------------------------
Fix Version/s: 9.0
Resolution: Done
Marking as resolved based upon Kylin's fix.
> Examples dynamicvdb-restservice - rest client returns always empty body
> ------------------------------------------------------------------------
>
> Key: TEIID-4204
> URL: https://issues.jboss.org/browse/TEIID-4204
> Project: Teiid
> Issue Type: Bug
> Components: Quick Starts
> Affects Versions: 8.12.5
> Reporter: Van Halbert
> Assignee: Kylin Soong
> Priority: Minor
> Fix For: 9.0
>
>
> Description of problem:
> rest-client returns always empty body for every request like follows:
> [jdurani@localhost resteasy-client]$ java -cp target/dependency/*:target/dynamicvdb-resteasy-client.jar org.jboss.teiid.quickstart.PortfolioClient
> JAX-RS 2.0 Client API
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-4122) Improve performance of odbc client column metadata query
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4122?page=com.atlassian.jira.plugin... ]
Steven Hawkins reassigned TEIID-4122:
-------------------------------------
Assignee: Steven Hawkins
> Improve performance of odbc client column metadata query
> --------------------------------------------------------
>
> Key: TEIID-4122
> URL: https://issues.jboss.org/browse/TEIID-4122
> Project: Teiid
> Issue Type: Quality Risk
> Components: ODBC
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> With cursoring, the client issues:
> select n.nspname, c.relname, a.attname, a.atttypid, t.typname, a.attnum, a.attlen, a.atttypmod, a.attnotnull, c.relhasrules, c.relkind, c.oid, pg_get_expr(d.adbin, d.adrelid), case t.typtype when 'd' then t.typbasetype else 0 end, t.typtypmod, c.relhasoids from (((pg_catalog.pg_class c inner join pg_catalog.pg_namespace n on n.oid = c.relnamespace and c.oid = <table oid>) inner join pg_catalog.pg_attribute a on (not a.attisdropped) and a.attnum > 0 and a.attrelid = c.oid) inner join pg_catalog.pg_type t on t.oid = a.atttypid) left outer join pg_attrdef d on a.atthasdef and d.adrelid = a.attrelid and d.adnum = a.attnum order by n.nspname, c.relname, attnum
> We should ensure that this is being planned optimally.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3509) Consolidate internal and external materialization management
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3509?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3509 at 5/18/16 7:13 AM:
-------------------------------------------------------------
> 1) The execution looks correct, what is the error you are seeing?
I was gotten confused by the document, but if look at the source code it's easy to make sense
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
Note that Key is the PK column, but PK may contain more columns, VARIADIC KeyOther is for others, so if the mat view looks(only 1 column id is the PK)
{code}
+-----+----+----+----+
| id | a | b | c |
+-----+----+----+----+
| 100 | a0 | b0 | c0 |
| 101 | a1 | b1 | c1 |
| 102 | a2 | b2 | c2 |
+-----+----+----+----+
{code}
The SQL
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', '102'))
{code}
is not make sense. If want update two rows use
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101',), ('102',))
{code}
If PK have more columns, for example, id, a and b compose of the PK, then
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', 'a1', 'b1'), ('102', 'a2', 'b2'));
{code}
will update 2 rows, I will update the document.
was (Author: kylin):
> 1) The execution looks correct, what is the error you are seeing?
I was gotten confused by the document, but if look at the source code it's easy to make sense
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
Note that Key is the PK column, but PK may contain more columns, VARIADIC KeyOther is for others, so if the mat view looks(only 1 column id is the PK)
{code}
+-----+----+----+----+
| id | a | b | c |
+-----+----+----+----+
| 100 | a0 | b0 | c0 |
| 101 | a1 | b1 | c1 |
| 102 | a2 | b2 | c2 |
+-----+----+----+----+
{code}
The SQL
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', '102'))
{code}
is not make sense. If want update two rows use
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101',), ('102',))
{code}
If PK have more columns, for example, id, a and b compose of the PK, then
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', 'a1', 'b1'), ('102', 'a2', 'b2'));
{code}
will update 2 rows, I will update the document.
By the way, as per Steven's comment in yesterday's meeting, refresh via PK is related with cluster, but current external update not use primary key, does this fine?
> Consolidate internal and external materialization management
> ------------------------------------------------------------
>
> Key: TEIID-3509
> URL: https://issues.jboss.org/browse/TEIID-3509
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> - Currently there separate SYSADMIN procedures for internal and external materialization to refresh them, we need to provide single set
> - The management of the (usage of status table) is not fully utilized by the internal materialization this needs to addressed such that both external and internal use this table to keep track of load status
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3509) Consolidate internal and external materialization management
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3509?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3509 at 5/18/16 6:19 AM:
-------------------------------------------------------------
> 1) The execution looks correct, what is the error you are seeing?
I was gotten confused by the document, but if look at the source code it's easy to make sense
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
Note that Key is the PK column, but PK may contain more columns, VARIADIC KeyOther is for others, so if the mat view looks(only 1 column id is the PK)
{code}
+-----+----+----+----+
| id | a | b | c |
+-----+----+----+----+
| 100 | a0 | b0 | c0 |
| 101 | a1 | b1 | c1 |
| 102 | a2 | b2 | c2 |
+-----+----+----+----+
{code}
The SQL
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', '102'))
{code}
is not make sense. If want update two rows use
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101',), ('102',))
{code}
If PK have more columns, for example, id, a and b compose of the PK, then
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', 'a1', 'b1'), ('102', 'a2', 'b2'));
{code}
will update 2 rows, I will update the document.
By the way, as per Steven's comment in yesterday's meeting, refresh via PK is related with cluster, but current external update not use primary key, does this fine?
was (Author: kylin):
> 1) The execution looks correct, what is the error you are seeing?
I was gotten confused by the document, but if look at the source code it's easy to make sense
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
Note that Key is the PK column, but PK may contain more columns, VARIADIC KeyOther is for others, so if the mat view looks(only 1 column id is the PK)
{code}
+-----+----+----+----+
| id | a | b | c |
+-----+----+----+----+
| 100 | a0 | b0 | c0 |
| 101 | a1 | b1 | c1 |
| 102 | a2 | b2 | c2 |
+-----+----+----+----+
{code}
The SQL
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', '102'))
{code}
is not make sense. If PK have more columns, for example, id, a and b compose of the PK, then
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', 'a1', 'b1'));
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('102', 'a2', 'b2'))
{code}
Will work, each SQL only update one row. I will update the document.
By the way, as per Steven's comment in yesterday meeting, refresh via PK is related with cluster, but current external update not use primary key, does this fine?
> Consolidate internal and external materialization management
> ------------------------------------------------------------
>
> Key: TEIID-3509
> URL: https://issues.jboss.org/browse/TEIID-3509
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> - Currently there separate SYSADMIN procedures for internal and external materialization to refresh them, we need to provide single set
> - The management of the (usage of status table) is not fully utilized by the internal materialization this needs to addressed such that both external and internal use this table to keep track of load status
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3509) Consolidate internal and external materialization management
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3509?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3509 at 5/18/16 6:14 AM:
-------------------------------------------------------------
> 1) The execution looks correct, what is the error you are seeing?
I was gotten confused by the document, but if look at the source code it's easy to make sense
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
Note that Key is the PK column, but PK may contain more columns, VARIADIC KeyOther is for others, so if the mat view looks(only 1 column id is the PK)
{code}
+-----+----+----+----+
| id | a | b | c |
+-----+----+----+----+
| 100 | a0 | b0 | c0 |
| 101 | a1 | b1 | c1 |
| 102 | a2 | b2 | c2 |
+-----+----+----+----+
{code}
The SQL
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', '102'))
{code}
is not make sense. If PK have more columns, for example, id, a and b compose of the PK, then
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', 'a1', 'b1'));
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('102', 'a2', 'b2'))
{code}
Will work, each SQL only update one row. I will update the document.
By the way, as per Steven's comment in yesterday meeting, refresh via PK is related with cluster, but current external update not use primary key, does this fine?
was (Author: kylin):
> 1) The execution looks correct, what is the error you are seeing?
I was gotten confused by the document, but if look at the source code it's easy to make sense
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
Note that Key is the PK column, but PK more contain more columns, VARIADIC KeyOther is for others, so if the mat view looks(only 1 column id is the PK)
{code}
+-----+----+----+----+
| id | a | b | c |
+-----+----+----+----+
| 100 | a0 | b0 | c0 |
| 101 | a1 | b1 | c1 |
| 102 | a2 | b2 | c2 |
+-----+----+----+----+
{code}
The SQL
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', '102'))
{code}
is not make sense. If PK have more columns, for example, id, a and b compose of the PK, then
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', 'a1', 'b1'));
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('102', 'a2', 'b2'))
{code}
Will work, each SQL only update one row. I will update the document.
By the way, as per Steven's comment in yesterday meeting, refresh via PK is related with cluster, but current external update not use primary key, does this fine?
> Consolidate internal and external materialization management
> ------------------------------------------------------------
>
> Key: TEIID-3509
> URL: https://issues.jboss.org/browse/TEIID-3509
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> - Currently there separate SYSADMIN procedures for internal and external materialization to refresh them, we need to provide single set
> - The management of the (usage of status table) is not fully utilized by the internal materialization this needs to addressed such that both external and internal use this table to keep track of load status
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3509) Consolidate internal and external materialization management
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3509?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3509 at 5/18/16 3:03 AM:
-------------------------------------------------------------
> 1) The execution looks correct, what is the error you are seeing?
I was gotten confused by the document, but if look at the source code it's easy to make sense
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
Note that Key is the PK column, but PK more contain more columns, VARIADIC KeyOther is for others, so if the mat view looks(only 1 column id is the PK)
{code}
+-----+----+----+----+
| id | a | b | c |
+-----+----+----+----+
| 100 | a0 | b0 | c0 |
| 101 | a1 | b1 | c1 |
| 102 | a2 | b2 | c2 |
+-----+----+----+----+
{code}
The SQL
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', '102'))
{code}
is not make sense. If PK have more columns, for example, id, a and b compose of the PK, then
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', 'a1', 'b1'));
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('102', 'a2', 'b2'))
{code}
Will work, each SQL only update one row. I will update the document.
By the way, as per Steven's comment in yesterday meeting, refresh via PK is related with cluster, but current external update not use primary key, does this fine?
was (Author: kylin):
> 1) The execution looks correct, what is the error you are seeing?
I was gotten confused by the document, but if look at the source code it's easy to make sense
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
Note that Key is the PK column, but PK more contain more columns, VARIADIC KeyOther is for others, so if the mat view looks(only 1 column id is the PK)
{code}
+-----+----+----+----+
| id | a | b | c |
+-----+----+----+----+
| 100 | a0 | b0 | c0 |
| 101 | a1 | b1 | c1 |
| 102 | a2 | b2 | c2 |
+-----+----+----+----+
{code}
The SQL
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', '102'))
{code}
is not make sense. If PK have more columns, for example, id, a and b compose of the PK, then
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', 'a1', 'b1'));
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('102', 'a2', 'b2'))
{code}
Will work, each SQL only update one row.
> Consolidate internal and external materialization management
> ------------------------------------------------------------
>
> Key: TEIID-3509
> URL: https://issues.jboss.org/browse/TEIID-3509
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> - Currently there separate SYSADMIN procedures for internal and external materialization to refresh them, we need to provide single set
> - The management of the (usage of status table) is not fully utilized by the internal materialization this needs to addressed such that both external and internal use this table to keep track of load status
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3509) Consolidate internal and external materialization management
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3509?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3509:
------------------------------------
> 1) The execution looks correct, what is the error you are seeing?
I was gotten confused by the document, but if look at the source code it's easy to make sense
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
Note that Key is the PK column, but PK more contain more columns, VARIADIC KeyOther is for others, so if the mat view looks(only 1 column id is the PK)
{code}
+-----+----+----+----+
| id | a | b | c |
+-----+----+----+----+
| 100 | a0 | b0 | c0 |
| 101 | a1 | b1 | c1 |
| 102 | a2 | b2 | c2 |
+-----+----+----+----+
{code}
The SQL
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', '102'))
{code}
is not make sense. If PK have more columns, for example, id, a and b compose of the PK, then
{code}
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('101', 'a1', 'b1'));
EXEC SYSADMIN.refreshMatViewRows('TestInterMat.SAMPLEMATVIEW', ('102', 'a2', 'b2'))
{code}
Will work, each SQL only update one row.
> Consolidate internal and external materialization management
> ------------------------------------------------------------
>
> Key: TEIID-3509
> URL: https://issues.jboss.org/browse/TEIID-3509
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> - Currently there separate SYSADMIN procedures for internal and external materialization to refresh them, we need to provide single set
> - The management of the (usage of status table) is not fully utilized by the internal materialization this needs to addressed such that both external and internal use this table to keep track of load status
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3509) Consolidate internal and external materialization management
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3509?page=com.atlassian.jira.plugin... ]
Kylin Soong updated TEIID-3509:
-------------------------------
Comment: was deleted
(was: > 1) The execution looks correct, what is the error you are seeing?
The Procedure definition
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
have define a VARIADIC, but it not allow multiple pk added, for example, if execute
{code}
"EXEC SYSADMIN.refreshMatViewRow('TestInterMat.SAMPLEMATVIEW', '100', '101', '102')";
{code}
An exception will throw:
{code}
Caused by: org.teiid.api.exception.query.QueryProcessingException: TEIID30231 Materialized view TestInterMat.SAMPLEMATVIEW cannot have a row refreshed because the number of primary key elements 1 does not match the number of key arguments 3.
at org.teiid.query.tempdata.TempTableDataManager.updateMatviewRows(TempTableDataManager.java:437)
at org.teiid.query.tempdata.TempTableDataManager.handleSystemProcedures(TempTableDataManager.java:412)
at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:195)
{code}
This should be a bug, either update the Procedure definition remove VARIADIC, or update runtime make sure multiple rows can be updated, I prefer the later one.
I got confused from the document, according to
https://teiid.gitbooks.io/documents/content/reference/sysadmin_schema.html
SYSADMIN.refreshMatViewRow is for refreshing one row, and SYSADMIN.refreshMatViewRows is for refreshing multiple rows, but this is wrong, if look more about the procedures definition
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object)
CREATE FOREIGN PROCEDURE refreshMatViewRows(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, VARIADIC Key object[] NOT NULL)
{code}
* refreshMatViewRow is for updating one or more rows and PK only have one column
* refreshMatViewRows is for updating one or more rows and PK have more columns, a group of PK columns form a object array.)
> Consolidate internal and external materialization management
> ------------------------------------------------------------
>
> Key: TEIID-3509
> URL: https://issues.jboss.org/browse/TEIID-3509
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> - Currently there separate SYSADMIN procedures for internal and external materialization to refresh them, we need to provide single set
> - The management of the (usage of status table) is not fully utilized by the internal materialization this needs to addressed such that both external and internal use this table to keep track of load status
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3509) Consolidate internal and external materialization management
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3509?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3509 at 5/18/16 2:34 AM:
-------------------------------------------------------------
> 1) The execution looks correct, what is the error you are seeing?
The Procedure definition
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
have define a VARIADIC, but it not allow multiple pk added, for example, if execute
{code}
"EXEC SYSADMIN.refreshMatViewRow('TestInterMat.SAMPLEMATVIEW', '100', '101', '102')";
{code}
An exception will throw:
{code}
Caused by: org.teiid.api.exception.query.QueryProcessingException: TEIID30231 Materialized view TestInterMat.SAMPLEMATVIEW cannot have a row refreshed because the number of primary key elements 1 does not match the number of key arguments 3.
at org.teiid.query.tempdata.TempTableDataManager.updateMatviewRows(TempTableDataManager.java:437)
at org.teiid.query.tempdata.TempTableDataManager.handleSystemProcedures(TempTableDataManager.java:412)
at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:195)
{code}
This should be a bug, either update the Procedure definition remove VARIADIC, or update runtime make sure multiple rows can be updated, I prefer the later one.
I got confused from the document, according to
https://teiid.gitbooks.io/documents/content/reference/sysadmin_schema.html
SYSADMIN.refreshMatViewRow is for refreshing one row, and SYSADMIN.refreshMatViewRows is for refreshing multiple rows, but this is wrong, if look more about the procedures definition
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object)
CREATE FOREIGN PROCEDURE refreshMatViewRows(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, VARIADIC Key object[] NOT NULL)
{code}
* refreshMatViewRow is for updating one or more rows and PK only have one column
* refreshMatViewRows is for updating one or more rows and PK have more columns, a group of PK columns form a object array.
was (Author: kylin):
> 1) The execution looks correct, what is the error you are seeing?
The Procedure definition
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object) OPTIONS (UPDATECOUNT 1)
{code}
have define a VARIADIC, but it not allow multiple pk added, for example, if execute
{code}
"EXEC SYSADMIN.refreshMatViewRow('TestInterMat.SAMPLEMATVIEW', '100', '101', '102')";
{code}
An exception will throw:
{code}
Caused by: org.teiid.api.exception.query.QueryProcessingException: TEIID30231 Materialized view TestInterMat.SAMPLEMATVIEW cannot have a row refreshed because the number of primary key elements 1 does not match the number of key arguments 3.
at org.teiid.query.tempdata.TempTableDataManager.updateMatviewRows(TempTableDataManager.java:437)
at org.teiid.query.tempdata.TempTableDataManager.handleSystemProcedures(TempTableDataManager.java:412)
at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:195)
{code}
This should be a bug, either update the Procedure definition remove VARIADIC, or update runtime make sure multiple rows can be updated, I prefer the later one.
I got confused from the document, according to
https://teiid.gitbooks.io/documents/content/reference/sysadmin_schema.html
SYSADMIN.refreshMatViewRow is for refreshing one row, and SYSADMIN.refreshMatViewRows is for refreshing multiple rows, but this is wrong, if look more about the procedures definition
{code}
CREATE FOREIGN PROCEDURE refreshMatViewRow(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, IN Key object NOT NULL, VARIADIC KeyOther object)
CREATE FOREIGN PROCEDURE refreshMatViewRows(OUT RowsUpdated integer NOT NULL RESULT, IN ViewName string NOT NULL, VARIADIC Key object[] NOT NULL)
{code}
* refreshMatViewRow is for updating one or more rows and PK only have one column
* refreshMatViewRows is for updating one or more rows and PK have more columns, a group og PK columns form a object array.
> Consolidate internal and external materialization management
> ------------------------------------------------------------
>
> Key: TEIID-3509
> URL: https://issues.jboss.org/browse/TEIID-3509
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> - Currently there separate SYSADMIN procedures for internal and external materialization to refresh them, we need to provide single set
> - The management of the (usage of status table) is not fully utilized by the internal materialization this needs to addressed such that both external and internal use this table to keep track of load status
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months