[JBoss JIRA] (TEIIDSB-51) Define expectations for runtime metadata
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-51?page=com.atlassian.jira.plugi... ]
Ramesh Reddy edited comment on TEIIDSB-51 at 3/20/20 3:52 PM:
--------------------------------------------------------------
Only documentation is done, work to be done in TEIIDSB-180
was (Author: rareddy):
Only documentation
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-51
> URL: https://issues.redhat.com/browse/TEIIDSB-51
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: documentation
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 1.4.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.13.8#713008)
4 years, 2 months
[JBoss JIRA] (TEIIDSB-51) Define expectations for runtime metadata
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-51?page=com.atlassian.jira.plugi... ]
Ramesh Reddy updated TEIIDSB-51:
--------------------------------
Fix Version/s: 1.4.0
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-51
> URL: https://issues.redhat.com/browse/TEIIDSB-51
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: documentation
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 1.4.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.13.8#713008)
4 years, 2 months
[JBoss JIRA] (TEIIDSB-51) Define expectations for runtime metadata
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-51?page=com.atlassian.jira.plugi... ]
Ramesh Reddy resolved TEIIDSB-51.
---------------------------------
Resolution: Done
Only documentation
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-51
> URL: https://issues.redhat.com/browse/TEIIDSB-51
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: documentation
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 1.4.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.13.8#713008)
4 years, 2 months
[JBoss JIRA] (TEIIDSB-180) Define expectations for runtime metadata
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-180?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIIDSB-180:
---------------------------------
Story Points: (was: 1)
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-180
> URL: https://issues.redhat.com/browse/TEIIDSB-180
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: documentation
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
>
> 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.13.8#713008)
4 years, 2 months
[JBoss JIRA] (TEIIDSB-180) Define expectations for runtime metadata
by Ramesh Reddy (Jira)
Ramesh Reddy created TEIIDSB-180:
------------------------------------
Summary: Define expectations for runtime metadata
Key: TEIIDSB-180
URL: https://issues.redhat.com/browse/TEIIDSB-180
Project: Teiid Spring Boot
Issue Type: Feature Request
Components: documentation
Reporter: Steven Hawkins
Assignee: Ramesh Reddy
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.13.8#713008)
4 years, 2 months
[JBoss JIRA] (TEIIDSB-176) Add support for soap calls
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-176?page=com.atlassian.jira.plug... ]
Steven Hawkins updated TEIIDSB-176:
-----------------------------------
Original Estimate: 1 day, 2 hours
Remaining Estimate: 1 day, 2 hours
Affects: Documentation (Ref Guide, User Guide, etc.)
> Add support for soap calls
> --------------------------
>
> Key: TEIIDSB-176
> URL: https://issues.redhat.com/browse/TEIIDSB-176
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Components: datasource
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 1.5.0
>
> Original Estimate: 1 day, 2 hours
> Remaining Estimate: 1 day, 2 hours
>
> In the porting over of the rest logic the soap support was left off. We need to also support soap as a source.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (TEIID-5918) SQL Server uniqueidentifier field type: Conversion and concat errors, incorrect lower case comparisons
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5918?page=com.atlassian.jira.plugi... ]
Steven Hawkins resolved TEIID-5918.
-----------------------------------
Fix Version/s: 13.0.3
13.1.1
Resolution: Done
Updated the translator to more broadly use the char cast.
If you want more consistency with the case handling that should be logged as a separate issue. In the past we've had a few circumstances where users expect the source behavior rather than the virtualized. It would likely need to be driven off of the column case-sensitive metadata and be a system option and or per source.
> SQL Server uniqueidentifier field type: Conversion and concat errors, incorrect lower case comparisons
> ------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5918
> URL: https://issues.redhat.com/browse/TEIID-5918
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 13.1
> Reporter: Dmitrii Pogorelov
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 14.0, 13.0.3, 13.1.1
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining Estimate: 2 hours
>
> 1. when running the following queries:
> {code:sql}
> -- Check that the following queries don't fail and return correct results:
> -- Error: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 test_tables_ms: S0002 Unexpected exception while translating results: Conversion failed when converting from a character string to uniqueidentifier.
> select * from ms.test_uid where test_id != content ;;
> -- Should return all 16 rows
> -- Error: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 test_tables_ms: S0002 Unexpected exception while translating results: Conversion failed when converting from a character string to uniqueidentifier.
> select * from ms.test_uid t1 join ms.test_uid t2 on t1.test_id != t2.content ;;
> -- Should return 1 row
> -- Error: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 test_tables_ms: S0002 Unexpected exception while translating results: Conversion failed when converting from a character string to uniqueidentifier.
> select * from ms.test_uid where test_id in ('B279DD00-1B57-4567-ACA8-22D2693124F2', 'a', 'b') ;;
> {code}
> Teiid throws out the following error:
> {code}
> 2020-03-16 14:57:08,314 WARN [org.teiid.CONNECTOR] (Worker6_QueryProcessorQueue68) B9oE6Jwiki7f Connector worker process failed for atomic-request=B9oE6Jwiki7f.23.0.12: org.teiid.translator.TranslatorException: S0002 Unexpected exception while translating results: Conversion failed when converting from a character string to uniqueidentifier. at org.teiid.translator.jdbc.JDBCQueryExecution.next(JDBCQueryExecution.java:348) at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:475) at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:261) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:228) at com.sun.proxy.$Proxy43.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(FutureTask.java:266) at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:59) at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:281) at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:124) at org.teiid.dqp.internal.process.ThreadReuseExecutor$2.run(ThreadReuseExecutor.java:212) 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) Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Conversion failed when converting from a character string to uniqueidentifier. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:216) at com.microsoft.sqlserver.jdbc.SQLServerResultSet$FetchBuffer.nextRow(SQLServerResultSet.java:4853) at com.microsoft.sqlserver.jdbc.SQLServerResultSet.fetchBufferNext(SQLServerResultSet.java:1781) at com.microsoft.sqlserver.jdbc.SQLServerResultSet.next(SQLServerResultSet.java:1034) at org.jboss.jca.adapters.jdbc.WrappedResultSet.next(WrappedResultSet.java:2689) at org.teiid.translator.jdbc.JDBCQueryExecution.next(JDBCQueryExecution.java:334) ... 19 more
> {code}
> 2. when running the following queries:
> {code:sql}
> -- Check if concatenation of strings works correctly with uniqueidentifier column.
> -- Should return 4 rows anding with lowercased 'a'
> -- Error: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 test_tables_ms: 402 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT (g_0."test_id" + 'a') AS c_0 FROM "test_tables"."dbo"."test_uid" g_0 ORDER BY @@version OFFSET 0 ROWS FETCH NEXT 100 ROWS ONLY]
> select test_id || 'a' from ms.test_uid ;;
> {code}
> Teiid throws out the following error:
> {code}
> 2020-03-16 14:59:57,516 WARN [org.teiid.CONNECTOR] (Worker8_QueryProcessorQueue80) B9oE6Jwiki7f Connector worker process failed for atomic-request=B9oE6Jwiki7f.27.0.16: org.teiid.translator.jdbc.JDBCExecutionException: 402 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT (g_0."test_id" + 'a') AS c_0 FROM "test_tables"."dbo"."test_uid" g_0 ORDER BY @@version OFFSET 0 ROWS FETCH NEXT 100 ROWS ONLY] at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:127) at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:402) at sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:228) at com.sun.proxy.$Proxy43.execute(Unknown Source) at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:302) 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(FutureTask.java:266) at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:59) at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:281) at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:124) at org.teiid.dqp.internal.process.ThreadReuseExecutor$2.run(ThreadReuseExecutor.java:212) 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) Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The data types uniqueidentifier and varchar are incompatible in the add operator. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:216) at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1515) at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:404) at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:350) 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.SQLServerPreparedStatement.executeQuery(SQLServerPreparedStatement.java:285) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:504)
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:119) ... 17 more
> {code}
> 3. when running the following queries:
> {code:sql}
> -- Should return 0 rows
> -- FAILURE(result 1 result, lower case comparison)
> select * from ms.test_uid t1 join ms.test_uid t2 on t1.test_id = t2.test_id where t2.test_id = 'b279dd00-1b57-4567-aca8-22d2693124f2' ;;
> -- Should return 0 rows
> -- FAILURE(result 1 result, lower case comparison)
> select * from ms.test_uid where test_id = 'b279dd00-1b57-4567-aca8-22d2693124f2' ;;
> -- Should return 0 rows
> -- CORRECT
> select * from ms.test_uid where cast(cast(test_id as clob) as string) = 'b279dd00-1b57-4567-aca8-22d2693124f2' ;;
> {code}
> Teiid returns incorrect results.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (TEIIDSB-161) Excessive warning about spring.teiid.model.package
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-161?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIIDSB-161:
---------------------------------
Fix Version/s: (was: 1.4.x)
> Excessive warning about spring.teiid.model.package
> --------------------------------------------------
>
> Key: TEIIDSB-161
> URL: https://issues.redhat.com/browse/TEIIDSB-161
> Project: Teiid Spring Boot
> Issue Type: Bug
> Components: core
> Reporter: Steven Hawkins
> Priority: Minor
>
> when using a vdb project the warning:
> {code}
> 2020-01-17 17:03:22.491 WARN 6870 --- [ main] o.t.spring.autoconfigure.TeiidServer : ***************************************************************
> 2020-01-17 17:03:22.491 WARN 6870 --- [ main] o.t.spring.autoconfigure.TeiidServer : "spring.teiid.model.package" is NOT set, If you are using any custom translators, it is advised to that this property is set.
> 2020-01-17 17:03:22.491 WARN 6870 --- [ main] o.t.spring.autoconfigure.TeiidServer : consider setting this property to avoid time consuming scanning
> 2020-01-17 17:03:22.491 WARN 6870 --- [ main] o.t.spring.autoconfigure.TeiidServer : ***************************************************************
> {code}
> Seems unnecessary. Also what does it have to do with custom translators?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (TEIIDSB-51) Define expectations for runtime metadata
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-51?page=com.atlassian.jira.plugi... ]
Work on TEIIDSB-51 stopped by Ramesh Reddy.
-------------------------------------------
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-51
> URL: https://issues.redhat.com/browse/TEIIDSB-51
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: documentation
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
>
> 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.13.8#713008)
4 years, 2 months
[JBoss JIRA] (TEIIDSB-51) Define expectations for runtime metadata
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-51?page=com.atlassian.jira.plugi... ]
Ramesh Reddy updated TEIIDSB-51:
--------------------------------
Fix Version/s: (was: 1.4.0)
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-51
> URL: https://issues.redhat.com/browse/TEIIDSB-51
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: documentation
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
>
> 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.13.8#713008)
4 years, 2 months