April 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4106) Rename and align infinispan translators/resource-adapters for their purpose

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4106?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4106: ------------------------------- Git Pull Request: https://github.com/teiid/teiid/pull/660, https://github.com/teiid/teiid/pull/663 (was: https://github.com/teiid/teiid/pull/660) > Rename and align infinispan translators/resource-adapters for their purpose > ---------------------------------------------------------------------------- > > Key: TEIID-4106 > URL: https://issues.jboss.org/browse/TEIID-4106 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.0 > > > The infinispan-cache and infinispan-cache-dsl translators/resource-adapters need to be renamed and aligned for what their purpose is. Because using "dsl" as part of the name is confusing, because both translators now support querying using JDG DSL language. > infinispan-cache: > - rename to infinispan-cache-library-mode (or leave as infinispan-cache and it be assume library mode) > - deprecate the access to remote-cache because the other infinispan-cache-dsl translator provides this feature. > - this will enable the cleaning of the documentation to be specific to library mode > infinispan-cache-dsl: > - rename to infinispan-cache-hot-rod (or something other than "dsl") because this all about remote cache access using hot rod client -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4094) Move the packaging of teiid-jdbc.jar into is own project

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4094?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4094: ---------------------------------- Fix Version/s: (was: 9.0) I've reverted this change for master as we've also change the build structure there. I'll leave this open against 8.12.5 until it's determined whether a change is needed for the validation error. > Move the packaging of teiid-jdbc.jar into is own project > -------------------------------------------------------- > > Key: TEIID-4094 > URL: https://issues.jboss.org/browse/TEIID-4094 > Project: Teiid > Issue Type: Enhancement > Components: Build/Kits > Affects Versions: 8.12.x > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 8.12.5 > > > The issue with the way the teiid-jdbc.jar is packaged now, is that the teiid-web-console.zip gets included as a dependency. > {code} > [INFO] +- org.jboss.teiid:teiid:jar:jdbc:8.12.5.redhat-2:compile > [INFO] | \- org.jboss.teiid.web-console:teiid-console-dist:zip:jboss-as7:2.5.6.Final-redhat-63-4:compile > {code} > And that becomes an issue when other external projects to Teiid include the jdbc driver as a dependency, in that they also end up requiring the web-console.zip. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4121) Enhancing the External Materialization

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4121?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4121: --------------------------------------- > but currently, one VDB may have multiple "status" table, each view may have it's own "status" table. The primary reason for this is that we do not claim ownership of external materialization and the status table - where ever it is convenient for the vdb developer to locate the status, that's where it should be placed. If the vdb developer chooses to point all of the materializations at the same status table that is up to them. What you are probably wanting here is some kind of vdb global or default option. As Ramesh says though to keep our logic consistent it still needs to be exposed to use as a source. > 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. We don't need to throw an exception if extra properties are used - at worst that would be a warning. There are other circumstances though that do warrant validation that is not currently done - see TEIID-3999 > 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, 12 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3999) more aspects of materialization metadata should be validated

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3999?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3999: ---------------------------------- Fix Version/s: 9.1 > more aspects of materialization metadata should be validated > ------------------------------------------------------------ > > Key: TEIID-3999 > URL: https://issues.jboss.org/browse/TEIID-3999 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Priority: Minor > Fix For: 9.1 > > > During metadata load we should check if the status table and the materialization scripts are valid, so there is at least a log of the issue rather than waiting for the exception to occur once the vdb is active. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3725) In the JDG translators, enable named cache swapping so that materialization can be supported

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-3725: ------------------------------------- Assignee: Van Halbert (was: Steven Hawkins) Assigning back to Van. There probably needs to be a release note and documentation updates for this to be resolved. > In the JDG translators, enable named cache swapping so that materialization can be supported > -------------------------------------------------------------------------------------------- > > Key: TEIID-3725 > URL: https://issues.jboss.org/browse/TEIID-3725 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 8.12 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.0, 8.12.5 > > > The JDG translators, that in order to support materialization, will need to enable the named cache that's referenced by the connection, to be swapped. This is due to JDG doesn't currently support renaming a cache (i.e., like table rename in JDBC). And because of that, it limits how the cache can be refreshed (don't want to clear it before re-loading). > Ideas are: > 1. configure translator with the 2 cache names to use (a) initial cache to read from and (b) the staging cache to use > perform materialize load > call SYSADMIN.setProperty to trigger the swapping of the cache names > 2 ??? > Note: because there's no persistence in Teiid so that any cache name changes will outlive a server restart, when a restart occurs, the translator will read from the cache identified as the initial cache to read from. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4121) Enhancing the External Materialization

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4121?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4121: ------------------------------------- If the STATUS table is external, there is no good way to create this on deployment, unless we have an internal database that we can create on deployment. I think, we wanted to give the name of the Table to choice by the user, thus it can be defined on the VIEW property. What is the issue with having multiple tables? Note that each VIEW can be materialized a different database. > 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, 12 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4124) add literal date format YYYY-MM-DD to the SQL Server translator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4124?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4124. ----------------------------------- Fix Version/s: 9.0 8.12.5 Resolution: Done Updated the translator to generally support the DATE type for SQL Server 2008 + and to have specific handling for the default DATE formate yyyy-MM-dd. > add literal date format YYYY-MM-DD to the SQL Server translator > --------------------------------------------------------------- > > Key: TEIID-4124 > URL: https://issues.jboss.org/browse/TEIID-4124 > 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 > > > We are missing literal data format YYYY-MM-DD, which is 23 in our mapping for the sqlserver translator: > http://stackoverflow.com/questions/15555275/undocumented-convert-styles-d... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3177) Enforce SSL connections over ODBC when Encryption Mode is enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3177?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3177: ------------------------------------------------ Juraj Duráni <jdurani(a)redhat.com> changed the Status of [bug 1312455|https://bugzilla.redhat.com/show_bug.cgi?id=1312455] from ON_QA to VERIFIED > Enforce SSL connections over ODBC when Encryption Mode is enabled > ----------------------------------------------------------------- > > Key: TEIID-3177 > URL: https://issues.jboss.org/browse/TEIID-3177 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.8 > Reporter: Cristiano Nicolai > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.9, 8.7.5.6_2 > > > When connecting via ODBC transport, even if the encryption mode is set to enabled is still possible to establish non ssl connections. This allows clients to connect via insecure method. We would like that the Teiid transport could reject connections if they are not properly set up using SSL transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4114) Expanding logic in the format conversion for parsing and formatting of dates

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4114?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4114: ------------------------------------------------ Juraj Duráni <jdurani(a)redhat.com> changed the Status of [bug 1323312|https://bugzilla.redhat.com/show_bug.cgi?id=1323312] from ON_QA to VERIFIED > Expanding logic in the format conversion for parsing and formatting of dates > ---------------------------------------------------------------------------- > > Key: TEIID-4114 > URL: https://issues.jboss.org/browse/TEIID-4114 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5, 8.7.5.6_2 > > > Java documentation isn't explicit https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html regarding date/time formats. > The format string is not enforced on the parsing side, so any hour format will accept any value. However oracle's behavior is different - if you specify HH vs HH24, then 13-23 is disallowed. > Need to address this by expanding the logic in the format conversion to account for the difference between parsing and formatting. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3177) Enforce SSL connections over ODBC when Encryption Mode is enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3177?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3177: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1312455|https://bugzilla.redhat.com/show_bug.cgi?id=1312455] from ASSIGNED to ON_QA > Enforce SSL connections over ODBC when Encryption Mode is enabled > ----------------------------------------------------------------- > > Key: TEIID-3177 > URL: https://issues.jboss.org/browse/TEIID-3177 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.8 > Reporter: Cristiano Nicolai > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.9, 8.7.5.6_2 > > > When connecting via ODBC transport, even if the encryption mode is set to enabled is still possible to establish non ssl connections. This allows clients to connect via insecure method. We would like that the Teiid transport could reject connections if they are not properly set up using SSL transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues April 2016