[JBoss JIRA] (TEIID-5718) Provide a flag to disable alter statements
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5718?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5718.
-----------------------------------
Resolution: Done
Added org.teiid.allowAlter to control whether alter (and sysadmin.setproperty) is allowed at runtime. The rationale for this flag is that it allows for permission grants to be simple - grant all can be used and ephemeral metadata updates will not be allowed. If permissions are always set in a fine-grained manner, then this property does not need to be set. If no security is being used, this property can also be of use.
sysadmin set stats procedures are not affected by this property.
It is also possible to implement this at the validator level or through some changes to the default methods for MetadataRepository or ChainingMetadataRepository, but for now it was simplest to consolidate it onto DDLPlan.
> Provide a flag to disable alter statements
> ------------------------------------------
>
> Key: TEIID-5718
> URL: https://issues.jboss.org/browse/TEIID-5718
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
>
> The engine allows alter statements to ephemerally (by default) change view definitions, turn on/off triggers, etc. For Spring Boot and OpenShift deployment in particular we should consider whether this should be allowable/optional behavior.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (TEIID-5718) Provide a flag to disable alter statements
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5718?page=com.atlassian.jira.plugin... ]
Steven Hawkins moved TEIIDSB-68 to TEIID-5718:
----------------------------------------------
Project: Teiid (was: Teiid Spring Boot)
Key: TEIID-5718 (was: TEIIDSB-68)
Component/s: Query Engine
(was: core)
> Provide a flag to disable alter statements
> ------------------------------------------
>
> Key: TEIID-5718
> URL: https://issues.jboss.org/browse/TEIID-5718
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
>
> The engine allows alter statements to ephemerally (by default) change view definitions, turn on/off triggers, etc. For Spring Boot and OpenShift deployment in particular we should consider whether this should be allowable/optional behavior.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (TEIIDSB-68) Provide a flag to disable alter statements
by Steven Hawkins (Jira)
Steven Hawkins created TEIIDSB-68:
-------------------------------------
Summary: Provide a flag to disable alter statements
Key: TEIIDSB-68
URL: https://issues.jboss.org/browse/TEIIDSB-68
Project: Teiid Spring Boot
Issue Type: Quality Risk
Components: core
Reporter: Steven Hawkins
Assignee: Steven Hawkins
The engine allows alter statements to ephemerally (by default) change view definitions, turn on/off triggers, etc. For Spring Boot and OpenShift deployment in particular we should consider whether this should be allowable/optional behavior.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (TEIID-5713) Safesforce-41 translator errors
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5713?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5713:
-------------------------------------
In spring boot, I used the translator name as simple "salesforce", then depending upon which translator jar is in the classpath it will pick up that version of the Salesforce. Since the default URLs set for version 45, anything other than 45 used the translator is already putting out a warning, where the user has the ability to change the login URL to correct the issue.
> Safesforce-41 translator errors
> -------------------------------
>
> Key: TEIID-5713
> URL: https://issues.jboss.org/browse/TEIID-5713
> Project: Teiid
> Issue Type: Bug
> Components: Salesforce Connector
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.2, 11.2.3, 12.1.1
>
>
> Using the Salesforce-41 translator, just loading the metadata it fails with error. I have verified this with WF and SB. I think, it is probably better to switch this version to new version, and remove this version.
> {code}
> Caused by: com.sforce.ws.ConnectionException: ChangeEventHeader Not a valid enumeration for type: class com.sforce.soap.partner.SoapType
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readSingle(TypeMapper.java:668)
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readObject(TypeMapper.java:556)
> at com.force.api:41//com.sforce.soap.partner.Field.setSoapType(Field.java:1702)
> at com.force.api:41//com.sforce.soap.partner.Field.loadFields1(Field.java:2039)
> at com.force.api:41//com.sforce.soap.partner.Field.loadFields(Field.java:1912)
> at com.force.api:41//com.sforce.soap.partner.Field.load(Field.java:1906)
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readSingle(TypeMapper.java:674)
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readArray(TypeMapper.java:580)
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readObject(TypeMapper.java:558)
> at com.force.api:41//com.sforce.soap.partner.DescribeSObjectResult.setFields(DescribeSObjectResult.java:398)
> at com.force.api:41//com.sforce.soap.partner.DescribeSObjectResult.loadFields1(DescribeSObjectResult.java:1421)
> at com.force.api:41//com.sforce.soap.partner.DescribeSObjectResult.loadFields(DescribeSObjectResult.java:1350)
> at com.force.api:41//com.sforce.soap.partner.DescribeSObjectResult.load(DescribeSObjectResult.java:1344)
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readSingle(TypeMapper.java:674)
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readArray(TypeMapper.java:580)
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readObject(TypeMapper.java:558)
> at com.force.api:41//com.sforce.soap.partner.DescribeSObjectsResponse_element.setResult(DescribeSObjectsResponse_element.java:48)
> at com.force.api:41//com.sforce.soap.partner.DescribeSObjectsResponse_element.loadFields1(DescribeSObjectsResponse_element.java:107)
> at com.force.api:41//com.sforce.soap.partner.DescribeSObjectsResponse_element.loadFields(DescribeSObjectsResponse_element.java:83)
> at com.force.api:41//com.sforce.soap.partner.DescribeSObjectsResponse_element.load(DescribeSObjectsResponse_element.java:77)
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readSingle(TypeMapper.java:674)
> at com.force.api:41//com.sforce.ws.bind.TypeMapper.readObject(TypeMapper.java:556)
> at com.force.api:41//com.sforce.ws.transport.SoapConnection.bind(SoapConnection.java:180)
> at com.force.api:41//com.sforce.ws.transport.SoapConnection.receive(SoapConnection.java:154)
> at com.force.api:41//com.sforce.ws.transport.SoapConnection.send(SoapConnection.java:99)
> at com.force.api:41//com.sforce.soap.partner.PartnerConnection.describeSObjects(PartnerConnection.java:1225)
> at org.jboss.teiid.resource-adapter.salesforce-41@12.2.0-SNAPSHOT//org.teiid.resource.adapter.salesforce.SalesforceConnectionImpl.getObjectMetaData(SalesforceConnectionImpl.java:514)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (TEIID-5717) Timestamp fields fetch error with Cassandra
by Mark Tawk (Jira)
Mark Tawk created TEIID-5717:
--------------------------------
Summary: Timestamp fields fetch error with Cassandra
Key: TEIID-5717
URL: https://issues.jboss.org/browse/TEIID-5717
Project: Teiid
Issue Type: Bug
Reporter: Mark Tawk
Assignee: Steven Hawkins
I am getting the below error when fetching a Cassandra table containing a column of type timestamp
ERROR TEIID_CONNECTOR_LOGGER:92 (Worker1_QueryProcessorQueue117) - - [Connector worker process failed for atomic-request=bioF/LJOq1Ih.5.0.84] -
com.datastax.driver.core.exceptions.CodecNotFoundException: Codec not found for requested operation: [timestamp <-> com.datastax.driver.core.LocalDate]
at com.datastax.driver.core.CodecRegistry.notFound(CodecRegistry.java:741)
at com.datastax.driver.core.CodecRegistry.createCodec(CodecRegistry.java:588)
at com.datastax.driver.core.CodecRegistry.access$500(CodecRegistry.java:137)
at com.datastax.driver.core.CodecRegistry$TypeCodecCacheLoader.load(CodecRegistry.java:246)
at com.datastax.driver.core.CodecRegistry$TypeCodecCacheLoader.load(CodecRegistry.java:232)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3529)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2156)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2046)
at com.google.common.cache.LocalCache.get(LocalCache.java:3948)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3972)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4957)
at com.datastax.driver.core.CodecRegistry.lookupCodec(CodecRegistry.java:522)
at com.datastax.driver.core.CodecRegistry.codecFor(CodecRegistry.java:485)
at com.datastax.driver.core.CodecRegistry.codecFor(CodecRegistry.java:467)
at com.datastax.driver.core.AbstractGettableByIndexData.codecFor(AbstractGettableByIndexData.java:69)
at com.datastax.driver.core.AbstractGettableByIndexData.getDate(AbstractGettableByIndexData.java:174)
at com.datastax.driver.core.AbstractGettableData.getDate(AbstractGettableData.java:26)
at org.teiid.translator.cassandra.CassandraQueryExecution.getRow(CassandraQueryExecution.java:161)
at org.teiid.translator.cassandra.CassandraQueryExecution.next(CassandraQueryExecution.java:100)
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:428)
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:231)
at sun.reflect.GeneratedMethodAccessor624.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:216)
at com.sun.proxy.$Proxy61.more(Unknown Source)
at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:305)
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:104)
at java.util.concurrent.FutureTask.run(Unknown Source)
at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:61)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
The issue is solved in CassandraQueryExecution.java when replacing
case TIMESTAMP:
values.add(row.*getDate*(i));
with
case TIMESTAMP:
values.add(row.*getTimestamp*(i));
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (TEIIDSB-51) Define expectations for runtime metadata
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-51?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIIDSB-51:
----------------------------------
Fix Version/s: 1.1.0
(was: 1.0.4)
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-51
> URL: https://issues.jboss.org/browse/TEIIDSB-51
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.1.0
>
>
> At a high level there are potentially three modes for our ddl:
> 1. Interactive - there was some work toward this, but it needed to only be a "developer mode" as it would reload the vdb on each metadata change. There is a lot about the transactionality of DDL updates that our current simplistic metadata model does not support, which makes this hard to fully implement. We haven't talked about this much in relation to Teiid Spring Boot, but ideally there should be a way for developers to test incremental changes without full rebuilds.
> 2. Dynamic - the term is a bit dated, but this refers to any vdb that performs import from a metadata repository that has runtime dependencies. By design this allows for a simple vdb definition and options for caching or re-importing on reload. In a container environment metadata caching no longer makes sense unless we use a volume. Depending upon your viewpoint allowing for runtime import of metadata is potentially a point of mutability that is also not needed in a container environment.
> 3. Static - much like our old .index designer vdbs there are benefits to having the full metadata already available to the vdb/image. There is a lot of work that we do lazily at runtime that can be moved to an earlier phase - primarily generating the rest and odata layers, but it would also include the pg system table materializations. For Teiid Spring Boot or usage in containers in general what this would look like is a build phase for the vdb such that it could obtain appropriate metadata and initialize as much as possible statically (eventually for quarkus vm snapshotting). The only metadata that would not be fresh potentially would be the costing metadata - however that is problematic as is and will eventually need a progressive optimization strategy employing a persistent store.
> As of now we are currently focused just on #2. As we look toward operators, we should start thinking about #3.
> #1 would come into play if/when we start looking at local development options using vs code.
> We can treat this issue as an epic and a place to centralize discussion.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (TEIIDSB-51) Define expectations for runtime metadata
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-51?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIIDSB-51:
---------------------------------------
It's worth adding here that the vdb load process when using ddl is serial - each metadata load happens in turn as the ordering of the ddl statements is inherently serial. As there is no metadata caching for a ddl vdb either, every start of a "dynamic vdb" will incur the full metadata load cost.
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-51
> URL: https://issues.jboss.org/browse/TEIIDSB-51
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.0.4
>
>
> At a high level there are potentially three modes for our ddl:
> 1. Interactive - there was some work toward this, but it needed to only be a "developer mode" as it would reload the vdb on each metadata change. There is a lot about the transactionality of DDL updates that our current simplistic metadata model does not support, which makes this hard to fully implement. We haven't talked about this much in relation to Teiid Spring Boot, but ideally there should be a way for developers to test incremental changes without full rebuilds.
> 2. Dynamic - the term is a bit dated, but this refers to any vdb that performs import from a metadata repository that has runtime dependencies. By design this allows for a simple vdb definition and options for caching or re-importing on reload. In a container environment metadata caching no longer makes sense unless we use a volume. Depending upon your viewpoint allowing for runtime import of metadata is potentially a point of mutability that is also not needed in a container environment.
> 3. Static - much like our old .index designer vdbs there are benefits to having the full metadata already available to the vdb/image. There is a lot of work that we do lazily at runtime that can be moved to an earlier phase - primarily generating the rest and odata layers, but it would also include the pg system table materializations. For Teiid Spring Boot or usage in containers in general what this would look like is a build phase for the vdb such that it could obtain appropriate metadata and initialize as much as possible statically (eventually for quarkus vm snapshotting). The only metadata that would not be fresh potentially would be the costing metadata - however that is problematic as is and will eventually need a progressive optimization strategy employing a persistent store.
> As of now we are currently focused just on #2. As we look toward operators, we should start thinking about #3.
> #1 would come into play if/when we start looking at local development options using vs code.
> We can treat this issue as an epic and a place to centralize discussion.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (TEIIDSB-61) Not able to delete/create entity in
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-61?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIIDSB-61:
---------------------------------------
No, that effectively makes narayana a dependency for any write scenario. I'll see if I can provide an alternative.
> Not able to delete/create entity in
> ------------------------------------
>
> Key: TEIIDSB-61
> URL: https://issues.jboss.org/browse/TEIIDSB-61
> Project: Teiid Spring Boot
> Issue Type: Bug
> Reporter: Jan Safarik
> Assignee: Steven Hawkins
> Priority: Major
>
> Trying to use the teiid-spring-boot/samples/odata project, I am not able to Create, Update or Delete an entity. Tried on Customer, with Delete I get back code: TEIID30504 with message: "TEIID30504 accounts: 23503 TEIID11013:TEIID11004 Error executing statement(s): [SQL: DELETE FROM "CUSTOMER" WHERE "CUSTOMER"."SSN" = 'CST01002']". With Create (Post) I get code: TEIID30528 with message: "TEIID30528 javax.transaction.SystemException".
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (TEIIDSB-61) Not able to delete/create entity in
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-61?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIIDSB-61:
-------------------------------------
I added a small change to the code and updated the example, may you can take look at the changes required.
> Not able to delete/create entity in
> ------------------------------------
>
> Key: TEIIDSB-61
> URL: https://issues.jboss.org/browse/TEIIDSB-61
> Project: Teiid Spring Boot
> Issue Type: Bug
> Reporter: Jan Safarik
> Assignee: Steven Hawkins
> Priority: Major
>
> Trying to use the teiid-spring-boot/samples/odata project, I am not able to Create, Update or Delete an entity. Tried on Customer, with Delete I get back code: TEIID30504 with message: "TEIID30504 accounts: 23503 TEIID11013:TEIID11004 Error executing statement(s): [SQL: DELETE FROM "CUSTOMER" WHERE "CUSTOMER"."SSN" = 'CST01002']". With Create (Post) I get code: TEIID30528 with message: "TEIID30528 javax.transaction.SystemException".
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months