[JBoss JIRA] (TEIID-4008) Sending teiid varbinary value (x'') to Microsoft SQL Server errors
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4008?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-4008:
------------------------------------------------
Alex Szczuczko <aszczucz(a)redhat.com> changed the Status of [bug 1313407|https://bugzilla.redhat.com/show_bug.cgi?id=1313407] from MODIFIED to ON_QA
> Sending teiid varbinary value (x'') to Microsoft SQL Server errors
> ------------------------------------------------------------------
>
> Key: TEIID-4008
> URL: https://issues.jboss.org/browse/TEIID-4008
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.7.2.6_2
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.13.2, 8.7.5.6_2
>
>
> When sending a query to Microsoft SQL Server with a varbinary in criteria:
> select * from debBinary where ipv6= x'FFFF6BBE85D8'
> It pushes the criteria to Microsoft SQL Server, but as X'FFFF6BBE85D8'[1] so Microsoft gives the syntax error[2] and needs to just be select * from debBinary where ipv6= 'FFFF6BBE85D8':
> [1]14:26:08,951 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue8) Source-specific command: SELECT g_0."id", g_0."ipv6" FROM "bqt2"."dbo"."debbinary" g_0 WHERE g_0."ipv6" = X'FFFF6BBE85D8'
> [2] com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near 'FFFF6BBE85D8'.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4123) Issues with odbc metadata
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4123:
-------------------------------------
Summary: Issues with odbc metadata
Key: TEIID-4123
URL: https://issues.jboss.org/browse/TEIID-4123
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 8.7
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.0, 8.12.5, 8.13.4
The values that we are sending the client for atttypmod in the column when using cursoring results in the pg odbc client reissuing the column metadata query for most column types. Since the column metadata query is not that performant - TEIID-4122 - this results in significant overhead for wide selects.
We also don't have a pg_type entry for varbinary and may need to add more array types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4122) Improve performance of odbc client column metadata query
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4122:
-------------------------------------
Summary: 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)
8 years, 1 month
[JBoss JIRA] (TEIID-3582) Add the query requestID to all lines for that query in the logs
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3582?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3582.
---------------------------------
Resolution: Done
It's not enabled by default to keep the logs nominally the same from one release to the next - and not every log will be under an active request (such as asynch and admin tasks) so it can add clutter that some may not want.
> Add the query requestID to all lines for that query in the logs
> ---------------------------------------------------------------
>
> Key: TEIID-3582
> URL: https://issues.jboss.org/browse/TEIID-3582
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.12.5
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Fix For: 8.13, 8.12.2
>
>
> Currently when running a query, the logs show the requestId on most of the lines but not all, especially CONNECTOR.
> for example, the following line doesn't have it:
> 14:13:34,071 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue13) Source-specific command: ....
> That's the problem. When lots of queries are running, user wants to grep through the log for that requestid and get just that one query's stuff.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[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 updated TEIID-4121:
-------------------------------
Description:
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.
was:
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, but current one VDB may have multiple "status" table, each view may have a "status" table.
Further more, we can consider create status table automatically, which like internal, status create once VDB start, and configured in VDB scope.
> 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)
8 years, 1 month
[JBoss JIRA] (TEIID-3952) Update to updatable internal materialized view should update the materialized view as well as the database
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3952?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3952:
------------------------------------
[~andy.yuen], Sorry for late updating
{noformat}
1) select a row from the materialized table
2) update a field in a row in the materialized view
3) select that row (value unchanged ie, same as int 1) - tried multiple times
{noformat}
If you wait a little more time, which larger than the "teiid_rel:MATVIEW_TTL" you have configured in Mat view, then you can see the changed data. By default design, no matter internal Mat, or external Mat, a Timer Service used to synch database and materialized view, the Timer Service's period be configured via "teiid_rel:MATVIEW_TTL".
{noformat}
4) issue EXEC SYSADMIN.refreshMatViewRow(...) using primary key for the row that has been changed
5) select that row (value unchanged) - now I can see the changed data
{noformat}
SYSADMIN.refreshMatViewRow() will force update a row, so you see the update take effect at once.
> Update to updatable internal materialized view should update the materialized view as well as the database
> ----------------------------------------------------------------------------------------------------------
>
> Key: TEIID-3952
> URL: https://issues.jboss.org/browse/TEIID-3952
> Project: Teiid
> Issue Type: Enhancement
> Components: VDB
> Affects Versions: 8.7
> Environment: Red Hat JBoss Data Virtualization 6.2 based on Teiid 8.7.x
> Reporter: Andy Yuen
> Assignee: Kylin Soong
> Labels: jboss
> Fix For: 9.0
>
>
> Updating an updatable internal materized view updates the database but not the materialized view at present. The requested enhancement is that they, both, should be updated.
> Setup
> Client - SquirrelSQL to access JDV
> JDV 6.2 - with an updatable nternal materialized view of one table from the data source
> Data Source - just one data source: MySQL
> I can see from the console that the target table/view has been materialized
> Then I did the following:
> 1) select a row from the materialized table
> 2) update a field in a row in the materialized view
> 3) select that row (value unchanged ie, same as int 1) - tried multiple times
> 4) issue EXEC SYSADMIN.refreshMatViewRow(...) using primary key for the row that has been changed
> 5) select that row (value unchanged) - now I can see the changed data
> This behaviour is counter-intuitive because I was expecting that since it is an updatable materialized view, my change will write through the materialized view ie, change both the materialized view as well as the database. But in this case, it changed the database and not the materialized view?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-3582) Add the query requestID to all lines for that query in the logs
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-3582?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-3582:
------------------------------------
When I define following pattern:
{code:plain}
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %X{teiid-session} %X{teiid-request} %s%E%n
{code}
I see following log:
{code:plain}
07:17:29,334 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue1) Z2KH5qaowDl4 Z2KH5qaowDl4.0 Source-specific command: SELECT g_0.`id`, g_0.`name`, g_0.`address` FROM `dballo09`.`customers` AS g_0
{code}
I missed the information, that it shouldn't be enabled by default. In that case everything works as expected.
> Add the query requestID to all lines for that query in the logs
> ---------------------------------------------------------------
>
> Key: TEIID-3582
> URL: https://issues.jboss.org/browse/TEIID-3582
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.12.5
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Fix For: 8.12.2, 8.13
>
>
> Currently when running a query, the logs show the requestId on most of the lines but not all, especially CONNECTOR.
> for example, the following line doesn't have it:
> 14:13:34,071 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue13) Source-specific command: ....
> That's the problem. When lots of queries are running, user wants to grep through the log for that requestid and get just that one query's stuff.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[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 updated TEIID-4121:
-------------------------------
Description:
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, but current one VDB may have multiple "status" table, each view may have a "status" table.
Further more, we can consider create status table automatically, which like internal, status create once VDB start, and configured in VDB scope.
was:
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, but current one VDB may have multiple "status" table, each view may have a "status" table
Summary: Enhancing the External Materialization (was: Enhancing the Teiid Materialization)
> 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, but current one VDB may have multiple "status" table, each view may have a "status" table.
> Further more, we can consider create status table automatically, which like internal, status create once VDB start, and configured in VDB scope.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4121) Enhancing the Teiid Materialization
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4121?page=com.atlassian.jira.plugin... ]
Kylin Soong updated TEIID-4121:
-------------------------------
Description:
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, but current one VDB may have multiple "status" table, each view may have a "status" table
was:After some investigation
> Enhancing the Teiid 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, but current one VDB may have multiple "status" table, each view may have a "status" table
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month