[JBoss JIRA] (TEIID-4259) "TEIID30259 Cannot introduce new expressions" when using formattimestamp
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4259?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-4259.
---------------------------------
> "TEIID30259 Cannot introduce new expressions" when using formattimestamp
> ------------------------------------------------------------------------
>
> Key: TEIID-4259
> URL: https://issues.jboss.org/browse/TEIID-4259
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.11.3
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
>
> A certain query executes fine when using the normal timestamp column (w.valuetime). When this is changed to formattimestamp(w.valuetime, 'dd/MM/yyyy HH:mm') we get an exception complaining about a case statement that is part of the select a few columns after the particular valuetime column.
> 14:00:00,055 WARN [org.teiid.PROCESSOR] (Worker17615_QueryProcessorQueue95374) 7OLMH/JCvk3W TEIID30020 Processing exception for request 7OLMH/JCvk3W.48 'TEIID30259 Cannot introduce new expressions [CASE WHEN convert(anon_grp2.agg2, date) = convert(timestampadd(SQL_TSI_DAY, -1, convert(convert(now(), date), timestamp)), date) THEN 'Gisteren' ELSE CASE WHEN convert(anon_grp2.agg2, date) = convert(now(), date) THEN 'Vannacht' ELSE '' END END, CASE WHEN anon_grp2.agg3 IS NULL THEN 'Niet gemeten' ELSE 'OK' END, CASE WHEN anon_grp2.agg4 > 0 THEN 'OK' ELSE 'Ontbreekt' END] in duplicate removal.'. Originally QueryPlannerException RuleAssignOutputElements.java:407. Enable more detailed logging to see the entire stacktrace.
> This was the query that caused the problem:
> select w.patientid as Patientid,
> formattimestamp(w.valuetime,'yyyy-MM-dd HH:mm') as t2,
> w.valuetime as Tijdstip,
> max(w.bed) as Bed, max(w.Naam) as Naam,
> case when convert(max(w.opname), date) = timestampadd(SQL_TSI_DAY, -1, convert(now() , date)) then 'Gisteren'
> else
> case when convert(max(w.opname), date) = convert(now(), date) then 'Vannacht' else
> '' end end as Opname,
> case when count(w.MondZorgAantal) is null then 'Niet gemeten' else 'OK' end as Comfort,
> case when count(w.EvaluatieMond) > 0 then 'OK' else 'Ontbreekt' end as NRS
> from
> (
> select pi.patientid as Patientid, null as ValueTime, pi.bedabbr as Bed, concat(pi.PatientLastName, concat(', ',pi.PatientFirstName)) as Naam, pi.AdmTime as opname, null as MondZorgAantal, null as EvaluatieMond, patientStatusID
> from prod_PV_PatientInfo pi
> where pi.PatientStatusID = 1 and PatGroupAbbr like 'PICU%' and cast(pi.admTime as date) <> cast(now() as date)
> union
> select v.PatientID as Patientid, v.ValueTime, null as Bed, null as Naam, null as opname,
> v.c as MondZorgAantal, null as EvaluatieMond, v.PatientStatusID from
> (select obs1.PatientID, obs1.ValueTime, count(*) as c , pi.PatientStatusID
> from prod_PV_DerivedVariables obs1
> join prod_PV_PatientInfo pi on pi.PatientID = obs1.PatientID and pi.PatientStatusID = 1 and cast(pi.admTime as date) <> cast(now() as date) and PatGroupAbbr like 'PICU%'
> where obs1.variableid = 30010003
> and cast(valuetime as date) = timestampadd(SQL_TSI_DAY, -1, cast(now() as date))
> group by obs1.patientid, obs1.ValueTime, timestampadd(SQL_TSI_DAY, -1, cast(now() as date)), pi.PatientStatusID)v
> union
> select v.PatientID as Patientid, v.ValueTime, null as Bed, null as Naam, null as opname, null as MondZorgAantal, v.c as EvaluatieMond, v.PatientStatusID from
> (select obs1.PatientID, obs1.ValueTime, count(*) as c , pi.PatientStatusID
> from prod_PV_ObservationVariables obs1
> join prod_PV_PatientInfo pi on pi.PatientID = obs1.PatientID and pi.PatientStatusID = 1 and cast(pi.admTime as date) < cast(now() as date) and PatGroupAbbr like 'PICU%'
> where obs1.variableid = 15005534
> and cast(obs1.valuetime as date) = timestampadd(SQL_TSI_DAY, -1, cast(now() as date))
> group by obs1.patientid, obs1.ValueTime, timestampadd(SQL_TSI_DAY, -1, cast(now() as date)), pi.PatientStatusID)v
> ) w
> group by w.patientid, w.ValueTime
> order by max(w.bed)
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 1 month
[JBoss JIRA] (TEIID-4242) Google Spreadsheet gives 404 with ClientLogin Authentication Method
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4242?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-4242.
---------------------------------
> Google Spreadsheet gives 404 with ClientLogin Authentication Method
> -------------------------------------------------------------------
>
> Key: TEIID-4242
> URL: https://issues.jboss.org/browse/TEIID-4242
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.5.6_2
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
>
> Google spreadsheet resource adapter gives a 404[1] error when using ClientLogin Authentication method. Looking at the URL in the code it's set to https://www.google.com/accounts/ClientLogin and if you go manually to the Google login page it's https://accounts.google.com/ServiceLogin
> [1]
> 14:12:28,508 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (teiid-async-threads - 4) IJ000604: Throwable while attempting to get a new connection: null: org.teiid.resource.adapter.google.common.SpreadsheetAuthException: Error when attempting Client Login: 404: Not Found
> at org.teiid.resource.adapter.google.auth.ClientLoginHeaderFactory.login(ClientLoginHeaderFactory.java:80)
> at org.teiid.resource.adapter.google.SpreadsheetConnectionImpl.<init>(SpreadsheetConnectionImpl.java:76)
> at org.teiid.resource.adapter.google.SpreadsheetManagedConnectionFactory$1.getConnection(SpreadsheetManagedConnectionFactory.java:58)
> at org.teiid.resource.adapter.google.SpreadsheetManagedConnectionFactory$1.getConnection(SpreadsheetManagedConnectionFactory.java:55)
> at org.teiid.resource.spi.BasicManagedConnectionFactory.createManagedConnection(BasicManagedConnectionFactory.java:70) [teiid-api-8.7.6.6_2-redhat-1.jar:8.7.6.6_2-redhat-1]
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:858) [ironjacamar-core-impl-1.0.36.Final-redhat-1.jar:1.0.36.Final-redhat-1]
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:413) [ironjacamar-core-impl-1.0.36.Final-redhat-1.jar:1.0.36.Final-redhat-1]
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:457) [ironjacamar-core-impl-1.0.36.Final-redhat-1.jar:1.0.36.Final-redhat-1]
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:429) [ironjacamar-core-impl-1.0.36.Final-redhat-1.jar:1.0.36.Final-redhat-1]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:344) [ironjacamar-core-impl-1.0.36.Final-redhat-1.jar:1.0.36.Final-redhat-1]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:317) [ironjacamar-core-impl-1.0.36.Final-redhat-1.jar:1.0.36.Final-redhat-1]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:499) [ironjacamar-core-impl-1.0.36.Final-redhat-1.jar:1.0.36.Final-redhat-1]
> at org.teiid.resource.spi.WrappedConnectionFactory.getConnection(WrappedConnectionFactory.java:58) [teiid-api-8.7.6.6_2-redhat-1.jar:8.7.6.6_2-redhat-1]
> at org.teiid.translator.ExecutionFactory.getConnection(ExecutionFactory.java:181) [teiid-api-8.7.6.6_2-redhat-1.jar:8.7.6.6_2-redhat-1]
> at org.teiid.translator.ExecutionFactory.getConnection(ExecutionFactory.java:202) [teiid-api-8.7.6.6_2-redhat-1.jar:8.7.6.6_2-redhat-1]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:58) [teiid-engine-8.7.6.6_2-redhat-1.jar:8.7.6.6_2-redhat-1]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.7.6.6_2-redhat-1.jar:8.7.6.6_2-redhat-1]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:390) [teiid-jboss-integration-8.7.6.6_2-redhat-1.jar:8.7.6.6_2-redhat-1]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:439) [teiid-jboss-integration-8.7.6.6_2-redhat-1.jar:8.7.6.6_2-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 1 month
[JBoss JIRA] (TEIID-4295) TEIID31150 when using date function with MSSQL
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4295?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-4295.
---------------------------------
> TEIID31150 when using date function with MSSQL
> ----------------------------------------------
>
> Key: TEIID-4295
> URL: https://issues.jboss.org/browse/TEIID-4295
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
>
> I'm using teiid version 8.11.3
> I have a field of type date over mssql 2012, when applying a date function over it, i get directly the error :
> org.teiid.jdbc.TeiidSQLException: TEIID31150 The function 'YEAR(testmark.mydate)' is ambiguous. Use schema qualification.
> if I change the field type to datetime, the query executes successfully.
> Here is the simplified query i'm testing with:
> select YEAR("testmark"."mydate") as "testmark_mydate" from "implify_dataModel_at"."implify_data"."implify_red2"."testmark" "testmark" LIMIT 0 , 10
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 1 month
[JBoss JIRA] (TEIID-3511) usage of BITAND function in exists statement results in duplicate rows
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3511?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3511.
---------------------------------
> usage of BITAND function in exists statement results in duplicate rows
> ----------------------------------------------------------------------
>
> Key: TEIID-3511
> URL: https://issues.jboss.org/browse/TEIID-3511
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.9.1
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Attachments: debugplan_bitand.txt, debugplan_bitand_correct.txt, debugplan_nobitand.txt, debugplan_nobitand_correct.txt
>
>
> I've added the debug plan for the query without the BITAND function and with the BITAND function as an attachment.
> The version without the BITAND function returns 438 rows and the version with BITAND function returns 833 rows. I can see however that rows are duplicated in this second result. I've checked this by executing the version with BITAND statement with select *.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 1 month
[JBoss JIRA] (TEIID-4547) getQueryPlan fails in adminapi
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4547?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-4547 at 10/29/16 11:33 AM:
------------------------------------------------------------------
Committed with TEIID-4547 as the changes were more broad that just the operation name. The execution id also needed to be updated to type long and the execution would fail in domain mode.
was (Author: shawkins):
Added a better exception if we get unexpected results from domain mode.
Also generalized the domain logic such that we account for duplicate results and to handle a single non-list result.
Also switched to using linked hash collections to keep result ordering more stable.
> getQueryPlan fails in adminapi
> ------------------------------
>
> Key: TEIID-4547
> URL: https://issues.jboss.org/browse/TEIID-4547
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.1
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.2
>
>
> The adminapi is using get-plan, while the server is exposes the operation get-query-plan
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 1 month
[JBoss JIRA] (TEIID-4546) On setting jboss-teiid cluster : throwing java.lang.IllegalArgumentException.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4546?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4546.
-----------------------------------
Fix Version/s: (was: 9.0.5)
(was: 9.1.1)
Resolution: Done
Added a better exception if we get unexpected results from domain mode.
Also generalized the domain logic such that we account for duplicate results and to handle a single non-list result.
Also switched to using linked hash collections to keep result ordering more stable.
The exact issue in the forum of an empty result with getVDBs I was not able to reproduce however.
> On setting jboss-teiid cluster : throwing java.lang.IllegalArgumentException.
> -----------------------------------------------------------------------------
>
> Key: TEIID-4546
> URL: https://issues.jboss.org/browse/TEIID-4546
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi, Server, VDB
> Affects Versions: 8.13.x, 9.0.2
> Reporter: Kulbhushan Chaskar
> Assignee: Steven Hawkins
> Priority: Critical
> Labels: jboss
> Fix For: 9.2
>
>
> https://developer.jboss.org/thread/272755
> This will be to specifically address the adminclient issues in domain mode.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 1 month
[JBoss JIRA] (TEIID-4547) getQueryPlan fails in adminapi
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4547?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4547.
-----------------------------------
Resolution: Done
Added a better exception if we get unexpected results from domain mode.
Also generalized the domain logic such that we account for duplicate results and to handle a single non-list result.
Also switched to using linked hash collections to keep result ordering more stable.
> getQueryPlan fails in adminapi
> ------------------------------
>
> Key: TEIID-4547
> URL: https://issues.jboss.org/browse/TEIID-4547
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.1
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.2
>
>
> The adminapi is using get-plan, while the server is exposes the operation get-query-plan
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 1 month