[JBoss JIRA] (TEIID-5308) ENV() function doesn't resolve environment variables but system properties
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5308?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5308:
---------------------------------------
The proposal from the forum topic:
> How about creating separate functions, SYS_PROP(), and ENV_VAR() that do what they are supposed to do, and deprecate ENV() but keep it for backward compatibility?
I think that sounds good. I would want all of the functions exposed with the existing allowEnvFunction property.
[~rareddy] any thoughts?
> ENV() function doesn't resolve environment variables but system properties
> --------------------------------------------------------------------------
>
> Key: TEIID-5308
> URL: https://issues.jboss.org/browse/TEIID-5308
> Project: Teiid
> Issue Type: Bug
> Reporter: Mathieu Rampant
> Assignee: Steven Hawkins
> Priority: Critical
>
> the ENV() function, contrary to what its name suggests, doesn't look for environment variables but looks for system properties instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-5309) not null is not enforced for non-virtual system procedures
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5309?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5309.
-----------------------------------
Resolution: Done
Added the same check as performed in virtual procedures to non-virtual system procedures for null parameters. Also updated the logMsg function to accept a null message object and instead log the message 'null'.
> not null is not enforced for non-virtual system procedures
> ----------------------------------------------------------
>
> Key: TEIID-5309
> URL: https://issues.jboss.org/browse/TEIID-5309
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.3
>
>
> Just like with foreign physical procedures we assume that the non-null constraint is enforced at the data manager layer - however that logic doesn't exist for non-virtual system procedures. This leads to inconsistent behavior when using null literals and expressions that eventually evaluate to null.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-5310) updateMatView does not check for null validity
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-5310:
-------------------------------------
Summary: updateMatView does not check for null validity
Key: TEIID-5310
URL: https://issues.jboss.org/browse/TEIID-5310
Project: Teiid
Issue Type: Bug
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 10.3, 10.1.3, 10.2.1
updateMatView looks for validity from the status table, but only checks for NOT variables.valid - if there is no row in the status table this will pass that check.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-5184) Clob not supported in dynamic VDB
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-5184?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-5184:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1564648
Bugzilla Update: Perform
> Clob not supported in dynamic VDB
> ---------------------------------
>
> Key: TEIID-5184
> URL: https://issues.jboss.org/browse/TEIID-5184
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Aditi Patel
> Assignee: Steven Hawkins
> Fix For: 10.1, 9.3.6, 10.0.2
>
>
> I have updated the Jconnect driver. The current version is 7.07. Still I am facing some differnt error.
>
> {color:red}07:47:01,145 INFO [org.teiid.CONNECTOR] (Worker10_async-teiid-threads10) SybaseExecutionFactory Commit=true;DatabaseProductName=Sybase IQ;DatabaseProductVersion=SAP IQ/16.1.020.528/10528/P/sp02/Sun_x64/OS 5.11/64bit/2017-07-14 13:57:25;DriverMajorVersion=7;DriverMajorVersion=0;DriverName=jConnect (TM) for JDBC (TM);DriverVersion=jConnect (TM) for JDBC(TM)/7.07 SP133 (Build 27244)/P/EBF24376/JDK 1.6.0/jdbcmain/DEBUG/Thu Mar 26 04:57:02 PDT 2015;IsolationLevel=1
> 07:47:02,529 INFO [org.teiid.RUNTIME] (Worker9_async-teiid-threads9) TEIID50030 VDB ST_VDB.1 model "SrcModel_6" metadata loaded. End Time: 12/14/17 7:47 AM
> 07:47:07,194 INFO [org.teiid.RUNTIME] (Worker8_async-teiid-threads8) TEIID50030 VDB ST_VDB.1 model "SrcModel_2" metadata loaded. End Time: 12/14/17 7:47 AM
> 07:47:58,354 INFO [org.teiid.RUNTIME] (Worker10_async-teiid-threads10) TEIID50030 VDB ST_VDB.1 model "SrcModel_4" metadata loaded. End Time: 12/14/17 7:47 AM
> 07:48:03,510 INFO [org.teiid.RUNTIME.VDBLifeCycleListener] (Worker10_async-teiid-threads10) TEIID40003 VDB ST_VDB.1 is set to ACTIVE
>
> Error Log:
> 07:52:45,561 ERROR [org.teiid.PROCESSOR] (Worker7_QueryProcessorQueue425) Settto6t5XMi TEIID30019 Unexpected exception for request Settto6t5XMi.32: java.lang.NullPointerException
> at org.teiid.core.types.ClobImpl.<init>(ClobImpl.java:116)
> at org.teiid.common.buffer.LobManager.persistLob(LobManager.java:230)
> at org.teiid.common.buffer.LobManager.updateReferences(LobManager.java:141)
> at org.teiid.common.buffer.TupleBuffer.addTupleBatch(TupleBuffer.java:203)
> at org.teiid.query.processor.BatchCollector.flushBatchDirect(BatchCollector.java:230)
> at org.teiid.dqp.internal.process.RequestWorkItem$1.flushBatchDirect(RequestWorkItem.java:686)
> at org.teiid.query.processor.BatchCollector.flushBatch(BatchCollector.java:224)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:195)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:477)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:349)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:275)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
> 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)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {color}
> That looks to be a bug with the getSubString method of Sybase clobs. They are returning null when it is not expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-5096) Using /*+ MAKEDEP */ blocks the deploy proces when using DDL based vdb
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5096?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5096.
-----------------------------------
Resolution: Out of Date
Marking as out of date due to lack of progress.
> Using /*+ MAKEDEP */ blocks the deploy proces when using DDL based vdb
> ----------------------------------------------------------------------
>
> Key: TEIID-5096
> URL: https://issues.jboss.org/browse/TEIID-5096
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 9.3.3
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Attachments: threaddump.txt
>
>
> Hi,
> I've created a vdb that is depoyed using a vdb-ddl.ddl file.
> The deployment just stops and returned no error message when adding the SQL part below. Subsequent deployments are not handles. It seems like the deployment process just hangs. The only way to resolve this was to stop the wildfly server, remove the latest added content from the standalone/data/content directory and restart wildfly.
> {code:sql}
> CREATE VIEW tv_retrieve_monvals(
> admissionid integer not null,
> VariableID integer not null,
> Datetime timestamp not null,
> Entertime timestamp not null,
> varvalue double not null,
> primary key (admissionid, VariableID, Datetime)
> )
> AS
> SELECT v.PatientID AS admissionid, v.VariableID, v.Datetime, v.Entertime, v."Value" AS varvalue
> FROM (
> SELECT mv.PatientID, mv.VariableID, mv.Datetime, mv.Entertime, mv."Value",
> ROW_NUMBER() OVER (PARTITION BY mv.PatientID, mv.VariableID, mv.Datetime ORDER BY mv.Entertime DESC) AS rang
> FROM izisprod.P_GeneralData AS gd
> INNER JOIN /*+ MAKEDEP */ izisprod.P_MonVals AS mv ON
> gd.PatientID = mv.PatientID AND
> bitand(mv.Status, 8) = 8 AND
> bitand(mv.Status, 2) <> 2
> WHERE gd.Status = 1 OR (gd.Status >= 4 AND gd.Status <> 5)
> UNION
> SELECT mv.PatientID, mv.VariableID, mv.Datetime, mv.Entertime, mv."Value",
> ROW_NUMBER() OVER (PARTITION BY mv.PatientID, mv.VariableID, mv.Datetime ORDER BY mv.Entertime DESC) AS rang
> FROM iziswh.P_GeneralData AS gd
> INNER JOIN /*+ MAKEDEP */ iziswh.P_MonVals AS mv ON
> gd.PatientID = mv.PatientID AND
> bitand(mv.Status, 8) = 8 AND
> bitand(mv.Status, 2) <> 2
> ) AS v
> WHERE v.rang = 1;
> {code}
> Removing the /*+ MAKDEP */ references resolves the issue.
> I've tried creating a small ddl script that uses /*+ MAKEDEP */ to reproduce this issue but this script does deploy so currently I can not make a small example.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-5309) not null is not enforced for non-virtual system procedures
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-5309:
-------------------------------------
Summary: not null is not enforced for non-virtual system procedures
Key: TEIID-5309
URL: https://issues.jboss.org/browse/TEIID-5309
Project: Teiid
Issue Type: Bug
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 10.3
Just like with foreign physical procedures we assume that the non-null constraint is enforced at the data manager layer - however that logic doesn't exist for non-virtual system procedures. This leads to inconsistent behavior when using null literals and expressions that eventually evaluate to null.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-4934) Allow importing VDBs with conflicting model
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4934?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4934.
-----------------------------------
Resolution: Done
Updated the logic to check for a vdb that only imports other vdbs, then import only non-conflicting vdbs. Updated the docs with an example based upon this issue as well.
> Allow importing VDBs with conflicting model
> -------------------------------------------
>
> Key: TEIID-4934
> URL: https://issues.jboss.org/browse/TEIID-4934
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.3
> Environment: * Wildfly 10
> * Teiid Server 9.2.3
> Reporter: Pedro Inácio
> Assignee: Steven Hawkins
> Fix For: 10.3
>
>
> It should be possible to import a model via "_import-vdb_" that conflicts with other models also imported via "_import-vdb_" if the conflicting model has the same version.
> This will allow greater model reuse, and not to have duplicated model definitions in multiple vdbs.
> Example:
> VDB 1:
> <code>
> <vdb name="OneVDB" version="1">
> <description>One VDB</description>
> <import-vdb name=ConflictingVDB" version="1"/>
> <import-vdb name="OtherVDB" version="1"/>
> </code>
> VDB 2:
> <code>
> <vdb name="TwoVDB" version="1">
> <description>TwoVDB</description>
> <import-vdb name=ConflictingVDB" version="1"/>
> <import-vdb name="YetOtherVDB" version="1"/>
> </code>
> VDB 3:
> <code>
> <vdb name="ThirdVDB" version="1">
> <description>Third VDB</description>
> <import-vdb name=OneVDB" version="1"/>
> <import-vdb name="TwoVDB" version="1"/>
> </code>
> Currently we cannot use the ThirdVDB as is, since there is a conflicting VDB (ConflictingVDB) defined in VDBS One and Two.
> Since both are using the same version, it should be possible to ignore the conflict (via a property for example).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-4934) Allow importing VDBs with conflicting model
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4934?page=com.atlassian.jira.plugin... ]
Work on TEIID-4934 started by Steven Hawkins.
---------------------------------------------
> Allow importing VDBs with conflicting model
> -------------------------------------------
>
> Key: TEIID-4934
> URL: https://issues.jboss.org/browse/TEIID-4934
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.3
> Environment: * Wildfly 10
> * Teiid Server 9.2.3
> Reporter: Pedro Inácio
> Assignee: Steven Hawkins
> Fix For: 10.3
>
>
> It should be possible to import a model via "_import-vdb_" that conflicts with other models also imported via "_import-vdb_" if the conflicting model has the same version.
> This will allow greater model reuse, and not to have duplicated model definitions in multiple vdbs.
> Example:
> VDB 1:
> <code>
> <vdb name="OneVDB" version="1">
> <description>One VDB</description>
> <import-vdb name=ConflictingVDB" version="1"/>
> <import-vdb name="OtherVDB" version="1"/>
> </code>
> VDB 2:
> <code>
> <vdb name="TwoVDB" version="1">
> <description>TwoVDB</description>
> <import-vdb name=ConflictingVDB" version="1"/>
> <import-vdb name="YetOtherVDB" version="1"/>
> </code>
> VDB 3:
> <code>
> <vdb name="ThirdVDB" version="1">
> <description>Third VDB</description>
> <import-vdb name=OneVDB" version="1"/>
> <import-vdb name="TwoVDB" version="1"/>
> </code>
> Currently we cannot use the ThirdVDB as is, since there is a conflicting VDB (ConflictingVDB) defined in VDBS One and Two.
> Since both are using the same version, it should be possible to ignore the conflict (via a property for example).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months