[JBoss JIRA] (TEIID-3978) Remove AddressWrapper
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-3978?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-3978:
---------------------------------
Fix Version/s: 8.7.5.6_2
> Remove AddressWrapper
> ---------------------
>
> Key: TEIID-3978
> URL: https://issues.jboss.org/browse/TEIID-3978
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.0, 8.12.5, 8.13.2, 8.7.5.6_2
>
>
> AddressWrapper was introduced to handle an earlier jgroups version where address objects were not directly serializable. However the deserialization code is using the thread context class loader which is not guaranteed to have the JGroups classes in the classpath. The resulting exception (where the original exception is simply swallowed) looks like:
> {code}
> 2016-02-16 08:45:30,140 ERROR [Incoming-1,shared=tcp-teiid-1] org.teiid.replication.jgroups.JGroupsObjectReplicator$ReplicatorRpcDispatcher - exception marshalling object
> java.lang.IllegalStateException: unread block data
> at java.io.ObjectInputStream$BlockDataInputStream.setBlockDataMode(ObjectInputStream.java:2421)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1382)
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1706)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1344)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at org.jgroups.blocks.MethodCall.readExternal(MethodCall.java:430)
> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1837)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at org.teiid.replication.jgroups.JGroupsObjectReplicator$ContextAwareMarshaller.objectFromBuffer(JGroupsObjectReplicator.java:611)
> at org.teiid.replication.jgroups.JGroupsObjectReplicator$ReplicatorRpcDispatcher.handle(JGroupsObjectReplicator.java:106)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:484)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600)
> at org.jgroups.JChannel.up(JChannel.java:707)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (TEIID-3177) Enforce SSL connections over ODBC when Encryption Mode is enabled
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-3177?page=com.atlassian.jira.plugin... ]
Johnathon Lee closed TEIID-3177.
--------------------------------
Resolution: Done
> 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.7.5.6_2, 8.9
>
>
> 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)
10 years, 1 month
[JBoss JIRA] (TEIID-3177) Enforce SSL connections over ODBC when Encryption Mode is enabled
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-3177?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-3177:
---------------------------------
Fix Version/s: 8.7.5.6_2
> 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)
10 years, 1 month
[JBoss JIRA] (TEIID-3803) Kerberos with ODBC with MutualAuth fails
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3803?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-3803 at 3/8/16 12:15 PM:
--------------------------------------------------------------
There were couple issues,
1) The changes related to TEIID-3803 were lost during the merge of TEIID-3818 + TEIID-3874 + TEIID-3663
2) The changes related to TEIID-3375, where an additional "AuthenticationGssContinue" added, is failing with windows based client, where the client fails with dummy token used for login continuation for Teiid ODBC <-> JDBC session creation.
The fix is is avoid sending the "AuthenticationGssContinue" in the case when authentication succeeded, but no valid token is available.
The real issue is even though the "mutual auth" is turned on ODBC, with Active Directory there is no peer token provided at the end, KDC does. And sending a dummy token to a Linux ODBC client does not end up in error, where as Windows ODBC one does (which IMO is correct behavior).
The latest commit is address above issues correctly by not sending a "AuthenticationGssContinue" in the case where no peer token is issued.
was (Author: rareddy):
There were couple issues,
1) The changes related to TEIID-3803 were lot during the merge of TEIID-3818 + TEIID-3874 + TEIID-3663
2) The changes related to TEIID-3375, where an additional "AuthenticationGssContinue" added, is failing with windows based client, where the client fails with dummy token used for login continuation for Teiid ODBC <-> JDBC session creation.
The fix is is avoid sending the "AuthenticationGssContinue" in the case when authentication succeeded, but no valid token is available.
The real issue is even though the "mutual auth" is turned on ODBC, with Active Directory there is no peer token provided at the end, KDC does. And sending a dummy token to a Linux ODBC client does not end up in error, where as Windows ODBC one does (which IMO is correct behavior).
The latest commit is address above issues correctly by not sending a "AuthenticationGssContinue" in the case where no peer token is issued.
> Kerberos with ODBC with MutualAuth fails
> ----------------------------------------
>
> Key: TEIID-3803
> URL: https://issues.jboss.org/browse/TEIID-3803
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.7.2.6_2, 8.12.2, 8.13, 8.7.6
>
>
> When Active Directory is used for Kerberos authentication, and Windows ODBC client issues connection request it may fail with following exception.
> {code}
> 00:29:15,561 ERROR [org.teiid.ODBC] (New I/O worker #19) TEIID40015 Unexpected error occurred: org.teiid.client.security.LogonException: TEIID40014 Kerberos context login failed
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:203) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:236) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_79]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_79]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_79]
> at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:328) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
> Caused by: javax.security.auth.login.LoginException: TEIID50103 Wrong Response returned from teiid-security security domain; Expecting a Kerberoes response
> at org.teiid.jboss.JBossSessionService.buildGSSResult(JBossSessionService.java:138) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.jboss.JBossSessionService.neogitiateGssLogin(JBossSessionService.java:106) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.services.SessionServiceImpl.neogitiateGssLogin(SessionServiceImpl.java:545) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:173) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> ... 30 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (TEIID-3803) Kerberos with ODBC with MutualAuth fails
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3803?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3803.
---------------------------------
Resolution: Done
There were couple issues,
1) The changes related to TEIID-3803 were lot during the merge of TEIID-3818 + TEIID-3874 + TEIID-3663
2) The changes related to TEIID-3375, where an additional "AuthenticationGssContinue" added, is failing with windows based client, where the client fails with dummy token used for login continuation for Teiid ODBC <-> JDBC session creation.
The fix is is avoid sending the "AuthenticationGssContinue" in the case when authentication succeeded, but no valid token is available.
The real issue is even though the "mutual auth" is turned on ODBC, with Active Directory there is no peer token provided at the end, KDC does. And sending a dummy token to a Linux ODBC client does not end up in error, where as Windows ODBC one does (which IMO is correct behavior).
The latest commit is address above issues correctly by not sending a "AuthenticationGssContinue" in the case where no peer token is issued.
> Kerberos with ODBC with MutualAuth fails
> ----------------------------------------
>
> Key: TEIID-3803
> URL: https://issues.jboss.org/browse/TEIID-3803
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.7.6, 8.13, 8.12.2, 8.7.2.6_2
>
>
> When Active Directory is used for Kerberos authentication, and Windows ODBC client issues connection request it may fail with following exception.
> {code}
> 00:29:15,561 ERROR [org.teiid.ODBC] (New I/O worker #19) TEIID40015 Unexpected error occurred: org.teiid.client.security.LogonException: TEIID40014 Kerberos context login failed
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:203) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:236) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_79]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_79]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_79]
> at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:328) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
> Caused by: javax.security.auth.login.LoginException: TEIID50103 Wrong Response returned from teiid-security security domain; Expecting a Kerberoes response
> at org.teiid.jboss.JBossSessionService.buildGSSResult(JBossSessionService.java:138) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.jboss.JBossSessionService.neogitiateGssLogin(JBossSessionService.java:106) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.services.SessionServiceImpl.neogitiateGssLogin(SessionServiceImpl.java:545) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:173) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> ... 30 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (TEIID-4033) View model - named attributes in mapping statement are not automatically mapped to the corresponding column in the table definition
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4033?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-4033:
------------------------------------------------
dsteigne(a)redhat.com changed the Status of [bug 1315756|https://bugzilla.redhat.com/show_bug.cgi?id=1315756] from NEW to CLOSED
> View model - named attributes in mapping statement are not automatically mapped to the corresponding column in the table definition
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4033
> URL: https://issues.jboss.org/browse/TEIID-4033
> Project: Teiid
> Issue Type: Bug
> Components: VDB
> Affects Versions: 8.7.2.6_2
> Environment: Dynamic VDB:
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <vdb name="dollar" version="1">
> <description/>
> <property name="validationDateTime" value="Tue Mar 08 07:37:23 CST 2016"/>
> <property name="validationVersion" value="8.7.3"/>
> <model name="SOURCE_MODEL">
> <source connection-jndi-name="Debbie2" name="Debbie2" translator-name="postgresql"/>
> <metadata type="DDL"><![CDATA[
> CREATE FOREIGN TABLE mytable (
> id integer NOT NULL OPTIONS(NAMEINSOURCE '"id"', NATIVE_TYPE 'int4', CASE_SENSITIVE 'FALSE', FIXED_LENGTH 'TRUE', SEARCHABLE 'ALL_EXCEPT_LIKE'),
> name string(40) OPTIONS(NAMEINSOURCE '"name"', NATIVE_TYPE 'text'),
> age integer OPTIONS(NAMEINSOURCE '"age"', NATIVE_TYPE 'int4', CASE_SENSITIVE 'FALSE', FIXED_LENGTH 'TRUE', SEARCHABLE 'ALL_EXCEPT_LIKE'),
> address string(200) OPTIONS(NAMEINSOURCE '"address"', NATIVE_TYPE 'text'),
> CONSTRAINT pk_mytableid PRIMARY KEY(id)
> ) OPTIONS(NAMEINSOURCE '"public"."mytable"', CARDINALITY '3')
> ]]></metadata>
> </model>
> <model name="VIEW_MODEL" type="VIRTUAL">
> <metadata type="DDL"><![CDATA[
> CREATE VIEW MY_VIEW (
> ID integer NOT NULL,
> NAME string(40),
> ADDRESS string(200),
> CONSTRAINT FKI_MY_VIEW PRIMARY KEY(ID)
> )
> AS
> SELECT "ID" as ID, "ADDRESS" as ADDRESS, "NAME" as NAME FROM SOURCE_MODEL.mytable;
> ]]></metadata>
> </model>
> </vdb>
> Reporter: Debbie Steigner
> Assignee: Barry LaFond
>
> Unexpected sequential dependency between virtual table column order and mapping column sequence.
> The TEIID statement to create a virtual table goes like:
> CREATE VIEW TargetModelViewName (
> ColumnA … 1
> ColumnB … 2
> ColumnC …) … 3
> AS SELECT
> SourceModel.SourceTable.ColX AS ColumnA, 1
> SourceModel.SourceTable.ColY AS ColumnB, 2
> SourceModel.SourceTable.ColZ AS ColumnC; 3
> In any 4th+ generation query language a positional dependency is not expected, and therefore the following statement should also work, but fails in the TEIID
> CREATE VIEW TargetModelViewName (
> ColumnA … 1
> ColumnB … 2
> ColumnC …) … 3
> AS SELECT
> SourceModel.SourceTable.ColX AS ColumnA, 1
> SourceModel.SourceTable.ColZ AS ColumnC, 3
> SourceModel.SourceTable.ColY AS ColumnB; 2
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (TEIID-4033) View model - named attributes in mapping statement are not automatically mapped to the corresponding column in the table definition
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4033?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4033.
-----------------------------------
Resolution: Rejected
When defining a view it is expected that the the declared columns and the columns of the query expression match positionally. You can confirm this behavior with other databases, such as h2, postgresql, etc.
> View model - named attributes in mapping statement are not automatically mapped to the corresponding column in the table definition
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4033
> URL: https://issues.jboss.org/browse/TEIID-4033
> Project: Teiid
> Issue Type: Bug
> Components: VDB
> Affects Versions: 8.7.2.6_2
> Environment: Dynamic VDB:
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <vdb name="dollar" version="1">
> <description/>
> <property name="validationDateTime" value="Tue Mar 08 07:37:23 CST 2016"/>
> <property name="validationVersion" value="8.7.3"/>
> <model name="SOURCE_MODEL">
> <source connection-jndi-name="Debbie2" name="Debbie2" translator-name="postgresql"/>
> <metadata type="DDL"><![CDATA[
> CREATE FOREIGN TABLE mytable (
> id integer NOT NULL OPTIONS(NAMEINSOURCE '"id"', NATIVE_TYPE 'int4', CASE_SENSITIVE 'FALSE', FIXED_LENGTH 'TRUE', SEARCHABLE 'ALL_EXCEPT_LIKE'),
> name string(40) OPTIONS(NAMEINSOURCE '"name"', NATIVE_TYPE 'text'),
> age integer OPTIONS(NAMEINSOURCE '"age"', NATIVE_TYPE 'int4', CASE_SENSITIVE 'FALSE', FIXED_LENGTH 'TRUE', SEARCHABLE 'ALL_EXCEPT_LIKE'),
> address string(200) OPTIONS(NAMEINSOURCE '"address"', NATIVE_TYPE 'text'),
> CONSTRAINT pk_mytableid PRIMARY KEY(id)
> ) OPTIONS(NAMEINSOURCE '"public"."mytable"', CARDINALITY '3')
> ]]></metadata>
> </model>
> <model name="VIEW_MODEL" type="VIRTUAL">
> <metadata type="DDL"><![CDATA[
> CREATE VIEW MY_VIEW (
> ID integer NOT NULL,
> NAME string(40),
> ADDRESS string(200),
> CONSTRAINT FKI_MY_VIEW PRIMARY KEY(ID)
> )
> AS
> SELECT "ID" as ID, "ADDRESS" as ADDRESS, "NAME" as NAME FROM SOURCE_MODEL.mytable;
> ]]></metadata>
> </model>
> </vdb>
> Reporter: Debbie Steigner
> Assignee: Barry LaFond
>
> Unexpected sequential dependency between virtual table column order and mapping column sequence.
> The TEIID statement to create a virtual table goes like:
> CREATE VIEW TargetModelViewName (
> ColumnA … 1
> ColumnB … 2
> ColumnC …) … 3
> AS SELECT
> SourceModel.SourceTable.ColX AS ColumnA, 1
> SourceModel.SourceTable.ColY AS ColumnB, 2
> SourceModel.SourceTable.ColZ AS ColumnC; 3
> In any 4th+ generation query language a positional dependency is not expected, and therefore the following statement should also work, but fails in the TEIID
> CREATE VIEW TargetModelViewName (
> ColumnA … 1
> ColumnB … 2
> ColumnC …) … 3
> AS SELECT
> SourceModel.SourceTable.ColX AS ColumnA, 1
> SourceModel.SourceTable.ColZ AS ColumnC, 3
> SourceModel.SourceTable.ColY AS ColumnB; 2
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (TEIID-4033) View model - named attributes in mapping statement are not automatically mapped to the corresponding column in the table definition
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4033?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4033:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1315756
Bugzilla Update: Perform
> View model - named attributes in mapping statement are not automatically mapped to the corresponding column in the table definition
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4033
> URL: https://issues.jboss.org/browse/TEIID-4033
> Project: Teiid
> Issue Type: Bug
> Components: VDB
> Affects Versions: 8.7.2.6_2
> Environment: Dynamic VDB:
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <vdb name="dollar" version="1">
> <description/>
> <property name="validationDateTime" value="Tue Mar 08 07:37:23 CST 2016"/>
> <property name="validationVersion" value="8.7.3"/>
> <model name="SOURCE_MODEL">
> <source connection-jndi-name="Debbie2" name="Debbie2" translator-name="postgresql"/>
> <metadata type="DDL"><![CDATA[
> CREATE FOREIGN TABLE mytable (
> id integer NOT NULL OPTIONS(NAMEINSOURCE '"id"', NATIVE_TYPE 'int4', CASE_SENSITIVE 'FALSE', FIXED_LENGTH 'TRUE', SEARCHABLE 'ALL_EXCEPT_LIKE'),
> name string(40) OPTIONS(NAMEINSOURCE '"name"', NATIVE_TYPE 'text'),
> age integer OPTIONS(NAMEINSOURCE '"age"', NATIVE_TYPE 'int4', CASE_SENSITIVE 'FALSE', FIXED_LENGTH 'TRUE', SEARCHABLE 'ALL_EXCEPT_LIKE'),
> address string(200) OPTIONS(NAMEINSOURCE '"address"', NATIVE_TYPE 'text'),
> CONSTRAINT pk_mytableid PRIMARY KEY(id)
> ) OPTIONS(NAMEINSOURCE '"public"."mytable"', CARDINALITY '3')
> ]]></metadata>
> </model>
> <model name="VIEW_MODEL" type="VIRTUAL">
> <metadata type="DDL"><![CDATA[
> CREATE VIEW MY_VIEW (
> ID integer NOT NULL,
> NAME string(40),
> ADDRESS string(200),
> CONSTRAINT FKI_MY_VIEW PRIMARY KEY(ID)
> )
> AS
> SELECT "ID" as ID, "ADDRESS" as ADDRESS, "NAME" as NAME FROM SOURCE_MODEL.mytable;
> ]]></metadata>
> </model>
> </vdb>
> Reporter: Debbie Steigner
> Assignee: Barry LaFond
>
> Unexpected sequential dependency between virtual table column order and mapping column sequence.
> The TEIID statement to create a virtual table goes like:
> CREATE VIEW TargetModelViewName (
> ColumnA … 1
> ColumnB … 2
> ColumnC …) … 3
> AS SELECT
> SourceModel.SourceTable.ColX AS ColumnA, 1
> SourceModel.SourceTable.ColY AS ColumnB, 2
> SourceModel.SourceTable.ColZ AS ColumnC; 3
> In any 4th+ generation query language a positional dependency is not expected, and therefore the following statement should also work, but fails in the TEIID
> CREATE VIEW TargetModelViewName (
> ColumnA … 1
> ColumnB … 2
> ColumnC …) … 3
> AS SELECT
> SourceModel.SourceTable.ColX AS ColumnA, 1
> SourceModel.SourceTable.ColZ AS ColumnC, 3
> SourceModel.SourceTable.ColY AS ColumnB; 2
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month