[JBoss JIRA] (TEIID-4151) AssertionError: Delete failed
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4151?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4151:
---------------------------------------
I'll try to reproduce based upon what you have here. Do you know if this still occurs on later Teiid versions?
> AssertionError: Delete failed
> -----------------------------
>
> Key: TEIID-4151
> URL: https://issues.jboss.org/browse/TEIID-4151
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.11.3
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
>
> When using a query like
> insert into #CaresequencesDaily
> some large select;
> delete
> from #CaresequencesDaily
> where datum < (select cast(startime as date) from #period);
> delete
> from #CaresequencesDaily
> where datum > (select cast(endtime as date) from #period);
> We get the following exception on the execution of the second delete query. It seems it does not matter in what order the delete queries are executed.
> Unexpected exception for request lMZm1kGe28/C.24: java.lang.AssertionError: Delete failed
> at org.teiid.query.tempdata.TempTable.deleteTuple(TempTable.java:801) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.tempdata.TempTable.access$500(TempTable.java:83) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.tempdata.TempTable$2.tuplePassed(TempTable.java:775) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.tempdata.TempTable$UpdateProcessor.process(TempTable.java:257) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.tempdata.TempTable.delete(TempTable.java:783) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.tempdata.TempTableDataManager$1.createTupleSource(TempTableDataManager.java:242) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.tempdata.TempTableDataManager$ProxyTupleSource.nextTuple(TempTableDataManager.java:109) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:369) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:457) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:267) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.11.3.jar:8.11.3]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.11.3.jar:8.11.3]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> I've tried to create a reproducable example but this doesn't throw the exception. It might be helpfull to understand what is goiing on.
> insert into #tmp_params
> select parsetimestamp('2016-04-01','yyyy-MM-dd') as starttime, parsetimestamp('2016-04-15','yyyy-MM-dd') as endtime;
> insert into #tmp_dates
> select cast(parsetimestamp('2016-03-20','yyyy-MM-dd') as date) as datum, 'somevalue' as somevalue
> UNION select cast(parsetimestamp('2016-04-02','yyyy-MM-dd') as date) as datum, 'somevalue' as somevalue
> UNION select cast(parsetimestamp('2016-04-20','yyyy-MM-dd') as date) as datum, 'somevalue' as somevalue;
> delete
> from #tmp_dates
> where datum > (select cast(endtime as date) from #tmp_params);
> --error is thrown when executing this second statement
> delete
> from #tmp_dates
> where datum < (select cast(starttime as date) from #tmp_params);
> select *
> from #tmp_dates
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3462:
---------------------------------------
Committed the change to use a string version field and tried to consolidate as much versioning logic on the VDBKey class as possible. The scheme is now:
vdb.1 -> is effectively short hand for vdb version 1.0.0, but we'll display the version as 1 for backwards compatibly.
.v is no longer needed. The version is just an expanded form -> vdb.1.1.1 will mean version 1.1.1.
qualifiers are not yet supported.
with rest we expect the url and the war name to use _ instead of . to match the old behavior.
with odata we'll default to the "1.0.0" version if none is specified.
> Add support for semantic versioning of VDBs
> -------------------------------------------
>
> Key: TEIID-3462
> URL: https://issues.jboss.org/browse/TEIID-3462
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.7
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon.
> [1] http://semver.org/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-3462 at 4/19/16 11:39 AM:
-----------------------------------------------------------------
After looking at the changes for rest, I'm uneasy with the current state of things. It does seem to be a better option to just go ahead and introduce a breaking change so that the version field can be a string rather than an int. This would introduce a minor breaking change into:
CommandLogMessage
VDB
Session
EventListener
VDBImport
ExecutionContext
MetadataRepository
Duplicate methods on:
EventDistributor
Admin
AdminShell could just accept Object for the version, rather than adding methods.
Additionally materialization status tables would need the vdbversion column changed to string.
This is much more logically consistent with the original intent of having the version field.
was (Author: shawkins):
After looking at the changes for rest, I'm uneasy with the current state of things. It does seem to be a better option to just go ahead and introduce a breaking change so that the version field can be a string rather than an int. This would introduce a minor breaking change into:
CommandLogMessage
VDB
Session
EventListener
VDBImport
ExecutionContext
Duplicate methods on:
EventDistributor
MetadataRepository
Admin
AdminShell could just accept Object for the version, rather than adding methods.
Additionally materialization status tables would need the vdbversion column changed to string.
This is much more logically consistent with the original intent of having the version field.
> Add support for semantic versioning of VDBs
> -------------------------------------------
>
> Key: TEIID-3462
> URL: https://issues.jboss.org/browse/TEIID-3462
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.7
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon.
> [1] http://semver.org/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-4129) Wrong results with cross model join on 2 varchar fields
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4129?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4129:
----------------------------------
Workaround Description: Set the translator property CollationLocale to any value that does not match the system property org.teiid.collationLocale (which is not required to be set).
Workaround: Workaround Exists
> Wrong results with cross model join on 2 varchar fields
> -------------------------------------------------------
>
> Key: TEIID-4129
> URL: https://issues.jboss.org/browse/TEIID-4129
> Project: Teiid
> Issue Type: Bug
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Attachments: H2 DBs.zip, MetaDataStores.zip
>
>
> I'm using Teiid 8.11.3 with H2 translator.
> I'm joining 2 h2 tables from 2 different teiid models linked on varchar fields.
> the query result is retuning empty values from the joined table even though the joined values are identical.
> You find attached a zip file containing 2 h2 DBs for a simplified example
> Here is the query used:
> _select "Customer"."City" as "Customer_City","Customer"."CustomerID" as "Customer_CustomerID","City"."City" as "City_City","City"."CityID" as "City_CityID"
> from "db2"."Customer" "Customer"
> LEFT JOIN "db1"."City" "City" ON "Customer"."City" = "City"."City"_
> Note that if the 2 tables are in the same model, the query return correct results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-4129) Wrong results with cross model join on 2 varchar fields
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4129?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4129:
---------------------------------------
CollationLocale currently only has meaning if it matches the system property value. And for this scenario it is not required to set the system property org.teiid.requireTeiidCollation=true
I'll see if there is a warning or other logic that would help prevent this from being an issue that requires a manual workaround.
> Wrong results with cross model join on 2 varchar fields
> -------------------------------------------------------
>
> Key: TEIID-4129
> URL: https://issues.jboss.org/browse/TEIID-4129
> Project: Teiid
> Issue Type: Bug
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Attachments: H2 DBs.zip, MetaDataStores.zip
>
>
> I'm using Teiid 8.11.3 with H2 translator.
> I'm joining 2 h2 tables from 2 different teiid models linked on varchar fields.
> the query result is retuning empty values from the joined table even though the joined values are identical.
> You find attached a zip file containing 2 h2 DBs for a simplified example
> Here is the query used:
> _select "Customer"."City" as "Customer_City","Customer"."CustomerID" as "Customer_CustomerID","City"."City" as "City_City","City"."CityID" as "City_CityID"
> from "db2"."Customer" "Customer"
> LEFT JOIN "db1"."City" "City" ON "Customer"."City" = "City"."City"_
> Note that if the 2 tables are in the same model, the query return correct results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-4146) Using JDG Library Mode, unable to perform insert (
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4146?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4146:
---------------------------------------
Is this now complete?
> Using JDG Library Mode, unable to perform insert (
> --------------------------------------------------
>
> Key: TEIID-4146
> URL: https://issues.jboss.org/browse/TEIID-4146
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.5
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Critical
>
> Trying to run the JDG local cache quickstart, get the following error when trying to perform an insert:
> 15:09:34,027 WARN [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue12) TEIID30020 Processing exception for request O25SlCY41bD5.6 'TEIID30492 Element StockCache.Stock.StockObject of StockCache.Stock is neither nullable nor has a default value. A value must be specified in the insert.'. Originally QueryValidatorException Request.java:330. Enable more detailed logging to see the entire stacktrace.
> The issue is because the StockObject column is set to be NullType.unknown, instead of NullType.Nullable. This is because the metadata processor in the translator-object is setting it incorrectly.
> Workaround:
> - Using Teiid Designer to import the source model and change the null type.
> - use dynamic vdb and define the DDL metadata to set the null type.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-4129) Wrong results with cross model join on 2 varchar fields
by Mark Tawk (JIRA)
[ https://issues.jboss.org/browse/TEIID-4129?page=com.atlassian.jira.plugin... ]
Mark Tawk commented on TEIID-4129:
----------------------------------
I have just set an arbitrary value into CollationLocale of the h2 translator and the problem was solved.
Is there any specific value to be set into CollationLocale?
> Wrong results with cross model join on 2 varchar fields
> -------------------------------------------------------
>
> Key: TEIID-4129
> URL: https://issues.jboss.org/browse/TEIID-4129
> Project: Teiid
> Issue Type: Bug
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Attachments: H2 DBs.zip, MetaDataStores.zip
>
>
> I'm using Teiid 8.11.3 with H2 translator.
> I'm joining 2 h2 tables from 2 different teiid models linked on varchar fields.
> the query result is retuning empty values from the joined table even though the joined values are identical.
> You find attached a zip file containing 2 h2 DBs for a simplified example
> Here is the query used:
> _select "Customer"."City" as "Customer_City","Customer"."CustomerID" as "Customer_CustomerID","City"."City" as "City_City","City"."CityID" as "City_CityID"
> from "db2"."Customer" "Customer"
> LEFT JOIN "db1"."City" "City" ON "Customer"."City" = "City"."City"_
> Note that if the 2 tables are in the same model, the query return correct results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-4151) AssertionError: Delete failed
by Bram Gadeyne (JIRA)
Bram Gadeyne created TEIID-4151:
-----------------------------------
Summary: AssertionError: Delete failed
Key: TEIID-4151
URL: https://issues.jboss.org/browse/TEIID-4151
Project: Teiid
Issue Type: Bug
Affects Versions: 8.11.3
Reporter: Bram Gadeyne
Assignee: Steven Hawkins
When using a query like
insert into #CaresequencesDaily
some large select;
delete
from #CaresequencesDaily
where datum < (select cast(startime as date) from #period);
delete
from #CaresequencesDaily
where datum > (select cast(endtime as date) from #period);
We get the following exception on the execution of the second delete query. It seems it does not matter in what order the delete queries are executed.
Unexpected exception for request lMZm1kGe28/C.24: java.lang.AssertionError: Delete failed
at org.teiid.query.tempdata.TempTable.deleteTuple(TempTable.java:801) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.tempdata.TempTable.access$500(TempTable.java:83) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.tempdata.TempTable$2.tuplePassed(TempTable.java:775) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.tempdata.TempTable$UpdateProcessor.process(TempTable.java:257) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.tempdata.TempTable.delete(TempTable.java:783) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.tempdata.TempTableDataManager$1.createTupleSource(TempTableDataManager.java:242) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.tempdata.TempTableDataManager$ProxyTupleSource.nextTuple(TempTableDataManager.java:109) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:369) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:457) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:267) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.11.3.jar:8.11.3]
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.11.3.jar:8.11.3]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
I've tried to create a reproducable example but this doesn't throw the exception. It might be helpfull to understand what is goiing on.
insert into #tmp_params
select parsetimestamp('2016-04-01','yyyy-MM-dd') as starttime, parsetimestamp('2016-04-15','yyyy-MM-dd') as endtime;
insert into #tmp_dates
select cast(parsetimestamp('2016-03-20','yyyy-MM-dd') as date) as datum, 'somevalue' as somevalue
UNION select cast(parsetimestamp('2016-04-02','yyyy-MM-dd') as date) as datum, 'somevalue' as somevalue
UNION select cast(parsetimestamp('2016-04-20','yyyy-MM-dd') as date) as datum, 'somevalue' as somevalue;
delete
from #tmp_dates
where datum > (select cast(endtime as date) from #tmp_params);
--error is thrown when executing this second statement
delete
from #tmp_dates
where datum < (select cast(starttime as date) from #tmp_params);
select *
from #tmp_dates
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (TEIID-4150) Infinispan dsl resource-adapter has not valid module.xml
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4150?page=com.atlassian.jira.plugin... ]
Van Halbert reassigned TEIID-4150:
----------------------------------
Assignee: Van Halbert (was: Steven Hawkins)
> Infinispan dsl resource-adapter has not valid module.xml
> --------------------------------------------------------
>
> Key: TEIID-4150
> URL: https://issues.jboss.org/browse/TEIID-4150
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Reporter: Jan Stastny
> Assignee: Van Halbert
>
> There is a problem in mentioned module when server attempts to load it:
> {code:plain}
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=infinispandsl:add(module=org.jboss.teiid.resource-adapter.infinispan.dsl)
> {
> "outcome" => "failed",
> "failure-description" => "JBAS010473: Failed to load module for RA [org.jboss.teiid.resource-adapter.infinispan.dsl]",
> "rolled-back" => true
> }
> {code}
> It is not valid module according to the 'urn:jboss:module:1.1' schema.
> Problematic fragment:
> {code:xml}
> <dependencies>
> ...
> <module name="org.infinispan.query" slot="jdg-6.6" optional="true" export="true" services="true" />
> ...
> </dependencies>
> {code}
> According to the mentioned schema the attribute 'services' can have only values:
> * none
> * import
> * export
> This issue prevents a user from using the adapter.
> Furthermore I am not sure that name 'org.infinispan.query' of the dependency module is correct. I haven't found such module in jdg client libs, there are two possible candidates though:
> * org.infinispan.query.dsl
> * org.infinispan.query.remote.client
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months