[JBoss JIRA] (TEIID-4605) SqlServer translator - insert/update statements - timestamp is cast to datetime
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-4605?page=com.atlassian.jira.plugin... ]
Juraj Duráni updated TEIID-4605:
--------------------------------
Description:
For update statements (insert, update), *timestamp* values are cast to *datatime* type. In MSSQL, this type's range start from year 1753 (1753\-01\-01...). However, there is *datetime2* type, which start from 0001\-01\-01.
This default cast to *datetime* prevents user from inserting value before year 1753 even if column in MSSQL is defined as datetime2.
Note: Specifying column option NATIVE_TYPE has no effect on this issue.
{code:plain|title=Stacktrace}
Connector worker process failed for atomic-request=7owuBqBS/Vow.1.0.3: org.teiid.translator.jdbc.JDBCExecutionException: 242 TEIID11013:TEIID11004 Error executing statement(s): [SQL: UPDATE SmallA SET TimestampValue = CAST('0100-02-03 04:05:06.0' AS DATETIME)]
at org.teiid.translator.jdbc.JDBCUpdateExecution.executeTranslatedCommand(JDBCUpdateExecution.java:293) [translator-jdbc-8.12.5.redhat-8.jar:8.12.5.redhat-8]
at org.teiid.translator.jdbc.JDBCUpdateExecution.execute(JDBCUpdateExecution.java:84) [translator-jdbc-8.12.5.redhat-8.jar:8.12.5.redhat-8]
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem$1.execute(ConnectorWorkItem.java:402)
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0-internal]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0-internal]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0-internal]
at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0-internal]
at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
at com.sun.proxy.$Proxy48.execute(Unknown Source)
at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0-internal]
at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-internal]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-internal]
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:216)
at com.microsoft.sqlserver.jdbc.TDSTokenHandler.onEOF(tdsparser.java:254)
at com.microsoft.sqlserver.jdbc.TDSParser.parse(tdsparser.java:84)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1510)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(SQLServerStatement.java:792)
at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(SQLServerStatement.java:689)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:5696)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1715)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:180)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:155)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeUpdate(SQLServerStatement.java:642)
at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:375)
at org.teiid.translator.jdbc.JDBCUpdateExecution.executeTranslatedCommand(JDBCUpdateExecution.java:207) [translator-jdbc-8.12.5.redhat-8.jar:8.12.5.redhat-8]
... 20 more
{code}
was:
For update statements (insert, update), *timestamp* values are cast to *datatime* type. In MSSQL, this type's range start from year 1753 (1753\-01\-01...). However, there is *datetime2* type, which start from 0001\-01\-01.
This default cast to *datetime* prevents user from inserting value before year 1753 even if column in MSSQL is defined as datetime2.
Note: Specifying column option NATIVE_TYPE has no effect on this issue.
> SqlServer translator - insert/update statements - timestamp is cast to datetime
> -------------------------------------------------------------------------------
>
> Key: TEIID-4605
> URL: https://issues.jboss.org/browse/TEIID-4605
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.12.5
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> For update statements (insert, update), *timestamp* values are cast to *datatime* type. In MSSQL, this type's range start from year 1753 (1753\-01\-01...). However, there is *datetime2* type, which start from 0001\-01\-01.
> This default cast to *datetime* prevents user from inserting value before year 1753 even if column in MSSQL is defined as datetime2.
> Note: Specifying column option NATIVE_TYPE has no effect on this issue.
> {code:plain|title=Stacktrace}
> Connector worker process failed for atomic-request=7owuBqBS/Vow.1.0.3: org.teiid.translator.jdbc.JDBCExecutionException: 242 TEIID11013:TEIID11004 Error executing statement(s): [SQL: UPDATE SmallA SET TimestampValue = CAST('0100-02-03 04:05:06.0' AS DATETIME)]
> at org.teiid.translator.jdbc.JDBCUpdateExecution.executeTranslatedCommand(JDBCUpdateExecution.java:293) [translator-jdbc-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.translator.jdbc.JDBCUpdateExecution.execute(JDBCUpdateExecution.java:84) [translator-jdbc-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem$1.execute(ConnectorWorkItem.java:402)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0-internal]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0-internal]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0-internal]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0-internal]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy48.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0-internal]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-internal]
> Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.
> at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:216)
> at com.microsoft.sqlserver.jdbc.TDSTokenHandler.onEOF(tdsparser.java:254)
> at com.microsoft.sqlserver.jdbc.TDSParser.parse(tdsparser.java:84)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1510)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(SQLServerStatement.java:792)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(SQLServerStatement.java:689)
> at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:5696)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1715)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:180)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:155)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeUpdate(SQLServerStatement.java:642)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:375)
> at org.teiid.translator.jdbc.JDBCUpdateExecution.executeTranslatedCommand(JDBCUpdateExecution.java:207) [translator-jdbc-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> ... 20 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (TEIID-4605) SqlServer translator - insert/update statements - timestamp is cast to datetime
by Juraj Duráni (JIRA)
Juraj Duráni created TEIID-4605:
-----------------------------------
Summary: SqlServer translator - insert/update statements - timestamp is cast to datetime
Key: TEIID-4605
URL: https://issues.jboss.org/browse/TEIID-4605
Project: Teiid
Issue Type: Bug
Affects Versions: 8.12.5
Reporter: Juraj Duráni
Assignee: Steven Hawkins
For update statements (insert, update), *timestamp* values are cast to *datatime* type. In MSSQL, this type's range start from year 1753 (1753\-01\-01...). However, there is *datetime2* type, which start from 0001\-01\-01.
This default cast to *datetime* prevents user from inserting value before year 1753 even if column in MSSQL is defined as datetime2.
Note: Specifying column option NATIVE_TYPE has no effect on this issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (TEIID-4298) Support in Odata4 for the Partner NavigationProperty attribute
by Mirco Marchitiello (JIRA)
[ https://issues.jboss.org/browse/TEIID-4298?page=com.atlassian.jira.plugin... ]
Mirco Marchitiello reopened TEIID-4298:
---------------------------------------
After the correction the following behaviour is correct:
Standard odata4:
http://services.odata.org/V4/Northwind/Northwind.svc/Categories(7)/Products
Teiid:
http:/localhost:8080/odata4/NORTHWIND.1/Northwind/Categories(7)/Products_FK_Products_Categories?$format=json
Anyway the following behaviour is still not permitted
Standard odata4:
http://services.odata.org/V4/Northwind/Northwind.svc/Products(51)/Categor...
Teiid:
http://localhost:8080/odata4/NORTHWIND.1/Northwind/Products(51)/Category/...
The message returned is
The property 'Products' must not follow a collection
I tried to change the properties
foreignKeyMultiplicity
primaryKeyMultiplicity
of the foreign key between Products and Categories with no success
> Support in Odata4 for the Partner NavigationProperty attribute
> --------------------------------------------------------------
>
> Key: TEIID-4298
> URL: https://issues.jboss.org/browse/TEIID-4298
> Project: Teiid
> Issue Type: Enhancement
> Components: OData
> Affects Versions: 9.0
> Reporter: Mirco Marchitiello
> Assignee: Ramesh Reddy
> Fix For: 9.1
>
>
> in Teiid 9.0 it would be useful to create a bidirectional link between tables, like in odata2
> for example:
> <EntityType Name="Product">
> <Key>
> <PropertyRef Name="ProductID"/>
> </Key>
> <Property Name="ProductID" Type="Edm.Int32" Nullable="false" p5:StoreGeneratedPattern="Identity"/>
> <Property Name="ProductName" Type="Edm.String" Nullable="false" MaxLength="40"/>
> <Property Name="SupplierID" Type="Edm.Int32"/>
> <Property Name="CategoryID" Type="Edm.Int32"/>
> <Property Name="QuantityPerUnit" Type="Edm.String" MaxLength="20"/>
> <Property Name="UnitPrice" Type="Edm.Decimal" Precision="19" Scale="4"/>
> <Property Name="UnitsInStock" Type="Edm.Int16"/>
> <Property Name="UnitsOnOrder" Type="Edm.Int16"/><Property Name="ReorderLevel" Type="Edm.Int16"/>
> <Property Name="Discontinued" Type="Edm.Boolean" Nullable="false"/>
> <NavigationProperty Name="Category" Type="NorthwindModel.Category" Partner="Products">
> <ReferentialConstraint Property="CategoryID" ReferencedProperty="CategoryID"/>
> </NavigationProperty>
> <NavigationProperty Name="Order_Details" Type="Collection(NorthwindModel.Order_Detail)" Partner="Product"/>
> <NavigationProperty Name="Supplier" Type="NorthwindModel.Supplier" Partner="Products">
> <ReferentialConstraint Property="SupplierID" ReferencedProperty="SupplierID"/>
> </NavigationProperty>
> </EntityType>
> <EntityType Name="Category">
> <Key>
> <PropertyRef Name="CategoryID"/>
> </Key>
> <Property Name="CategoryID" Type="Edm.Int32" Nullable="false" p5:StoreGeneratedPattern="Identity"/>
> <Property Name="CategoryName" Type="Edm.String" Nullable="false" MaxLength="15"/>
> <Property Name="Description" Type="Edm.String" MaxLength="max"/>
> <Property Name="Picture" Type="Edm.Binary" MaxLength="max"/>
> <NavigationProperty Name="Products" Type="Collection(NorthwindModel.Product)" Partner="Category"/>
> </EntityType>
> It seems that the two tables are related through NavigationProperty and Partner
> In fact I can see all the Categories of a certain Product
> http://services.odata.org/V4/Northwind/Northwind.svc/Products(10)/Category
> or viceversa the products of a certain Category
> http://services.odata.org/V4/Northwind/Northwind.svc/Categories(8)/Products
> While in Teiid using odata2 this works just by creating a FK from one table to the other one, with odata4 this does not happen
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (TEIID-4604) Insert issue when cache contains multiple pojo's with the same key value
by Van Halbert (JIRA)
Van Halbert created TEIID-4604:
----------------------------------
Summary: Insert issue when cache contains multiple pojo's with the same key value
Key: TEIID-4604
URL: https://issues.jboss.org/browse/TEIID-4604
Project: Teiid
Issue Type: Bug
Components: Misc. Connectors
Affects Versions: 9.2
Reporter: Van Halbert
Assignee: Van Halbert
Priority: Blocker
Fix For: 9.2, 8.12.8.6_3
There is an INSERT issue when there are multiple pojo's stored in the same cache and the keys' overlap (meaning the different types of pojo's have the same key).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (TEIID-4603) Insert issue when cache contains multiple pojo's with the same key value
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4603?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-4603:
------------------------------------
Part of the challenge is:
- Searching is done by using the DSL query language that performs the search by object type
- Insert/Update/Delete is done by put/remove from the map by the key
example of the issue:
- pojo A exist in the cache with key '1'.
- Insert is going to performed for pojo B with key '1'.
So when doing an insert for pojo 'B' key '1', a search is done and no object is returned for that type, so the the insert is performed. When pojo B is inserted with key '1', it will overlay pojo A with key '1'. Doing a search for pojo A will no longer return a row.
One thought is to do a cache.get(key) lookup on the cache to see if any existing object is there, instead of using the DSL searching.
> Insert issue when cache contains multiple pojo's with the same key value
> ------------------------------------------------------------------------
>
> Key: TEIID-4603
> URL: https://issues.jboss.org/browse/TEIID-4603
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 9.2
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Blocker
> Fix For: 9.2, 8.12.8.6_3
>
>
> There is an INSERT issue when there are multiple pojo's stored in the same cache and the keys' overlap (meaning the different types of pojo's have the same key).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (TEIID-4603) Insert issue when cache contains multiple pojo's with the same key value
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4603?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-4603:
------------------------------------
Part of the solution will be to add (something like the following) to documentation:
JDG Cache Design considerations:
- will the same cache contain multiple pojo's
- if yes, ensure the key is unique to the entire cache, which means it must also be unique across the other pojo's in the cache
> Insert issue when cache contains multiple pojo's with the same key value
> ------------------------------------------------------------------------
>
> Key: TEIID-4603
> URL: https://issues.jboss.org/browse/TEIID-4603
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 9.2
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Blocker
> Fix For: 9.2, 8.12.8.6_3
>
>
> There is an INSERT issue when there are multiple pojo's stored in the same cache and the keys' overlap (meaning the different types of pojo's have the same key).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (TEIID-4590) Fix the Select ALL logic so that it works when different object types exists
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4590?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4590:
-------------------------------
Comment: was deleted
(was: The issue is not fixed properly. I have two POJOs, two resource-adapters configured, single JDG instance and cache is used.
Tested usecase:
{code:sql}
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(1,'1',true);
SELECT * FROM jdgSource1.SmallA;
INSERT INTO jdgSource2.CustomerReport(customerId,totalAmount) VALUES(1,1);
SELECT * FROM jdgSource2.CustomerReport;
SELECT * FROM jdgSource1.SmallA;
{code}
Everything works as expected but the last query. It returns empty resultset, but there should be single row. (Second query returned correctly 1 row)
The issue seems to be that last INSERT somehow erases the previous contents.
When you try:
{code:sql}
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(1,'1',true);
INSERT INTO jdgSource2.CustomerReport(customerId,totalAmount) VALUES(1,1);
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(2,'2',false);
SELECT * FROM jdgSource1.SmallA;
{code}
you get only one row by the fourth query.
The reason is:
You have two POJOs, both have an id specified (different column names). When there is common Id value for different POJOs, in previous example it is value 1 for both 'intKey' and 'customerId', the object in jdg cache get overwritten. It is due to the fact, that objects in JDG are being stored in key-value way.
This is undesirable behaviour, because an object of one POJO class is overwritten by an object of different POJO class. This is blocking issue.
Note: if the id is unique across all POJOs inserted into single cache, this problem doesn't occur:
{code:sql}
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(1,'1',true);
INSERT INTO jdgSource2.CustomerReport(customerId,totalAmount) VALUES(3,3);
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(2,'2',false);
SELECT * FROM jdgSource1.SmallA;
{code}
in this case, correct values are being returned.
)
> Fix the Select ALL logic so that it works when different object types exists
> ----------------------------------------------------------------------------
>
> Key: TEIID-4590
> URL: https://issues.jboss.org/browse/TEIID-4590
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 9.2
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Blocker
> Fix For: 9.2, 8.12.8.6_3
>
>
> Fix the select * (ALL) logic so that it can work when there are multiple object types in the cache. The select ALL should only be selecting based on the object type associated with that table.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (TEIID-4603) Insert issue when cache contains multiple pojo's with the same key value
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4603?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-4603:
------------------------------------
I have two POJOs, two resource-adapters configured, single JDG instance and cache is used.
Tested usecase:
{code}
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(1,'1',true);
SELECT * FROM jdgSource1.SmallA;
INSERT INTO jdgSource2.CustomerReport(customerId,totalAmount) VALUES(1,1);
SELECT * FROM jdgSource2.CustomerReport;
SELECT * FROM jdgSource1.SmallA;
{code}
Everything works as expected but the last query. It returns empty resultset, but there should be single row. (Second query returned correctly 1 row)
The issue seems to be that last INSERT somehow erases the previous contents.
When you try:
{code}
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(1,'1',true);
INSERT INTO jdgSource2.CustomerReport(customerId,totalAmount) VALUES(1,1);
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(2,'2',false);
SELECT * FROM jdgSource1.SmallA;
{code}
you get only one row by the fourth query.
The reason is:
You have two POJOs, both have an id specified (different column names). When there is common Id value for different POJOs, in previous example it is value 1 for both 'intKey' and 'customerId', the object in jdg cache get overwritten. It is due to the fact, that objects in JDG are being stored in key-value way.
This is undesirable behaviour, because an object of one POJO class is overwritten by an object of different POJO class. This is blocking issue.
Note: if the id is unique across all POJOs inserted into single cache, this problem doesn't occur:
{code}
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(1,'1',true);
INSERT INTO jdgSource2.CustomerReport(customerId,totalAmount) VALUES(3,3);
INSERT INTO jdgSource1.SmallA(intKey,stringKey,booleanValue) VALUES(2,'2',false);
SELECT * FROM jdgSource1.SmallA;
{code}
in this case, correct values are being returned.
> Insert issue when cache contains multiple pojo's with the same key value
> ------------------------------------------------------------------------
>
> Key: TEIID-4603
> URL: https://issues.jboss.org/browse/TEIID-4603
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 9.2
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Blocker
> Fix For: 9.2, 8.12.8.6_3
>
>
> There is an INSERT issue when there are multiple pojo's stored in the same cache and the keys' overlap (meaning the different types of pojo's have the same key).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month