September 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIIDSB-42) Add a grafana dashboard example

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-42?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIIDSB-42: -------------------------------- Fix Version/s: 1.3.0 (was: 1.2.0) > Add a grafana dashboard example > ------------------------------- > > Key: TEIIDSB-42 > URL: https://issues.jboss.org/browse/TEIIDSB-42 > Project: Teiid Spring Boot > Issue Type: Sub-task > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.3.0 > > > Building off of the prometheus metrics collection, we should provide a grafana dashboard. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-45) Develop OpenShift Operator for deploying VDBs

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-45?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIIDSB-45. --------------------------------- Resolution: Done There is no more development going on for 0.0.1 version. So marking as resolved. Any issues will be handled as separate issues. > Develop OpenShift Operator for deploying VDBs > --------------------------------------------- > > Key: TEIIDSB-45 > URL: https://issues.jboss.org/browse/TEIIDSB-45 > Project: Teiid Spring Boot > Issue Type: Feature Request > Components: OpenShift > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Critical > Fix For: 1.2.0 > > > Need to develop a GO lang based Operator for deploying the VDBs and its configuration. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-51) Define expectations for runtime metadata

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-51?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIIDSB-51: -------------------------------- Fix Version/s: 1.3.0 (was: 1.2.0) > 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.3.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, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5819) rename translator-swagger to translator-openapi

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5819: ------------------------------------- Summary: rename translator-swagger to translator-openapi Key: TEIID-5819 URL: https://issues.jboss.org/browse/TEIID-5819 Project: Teiid Issue Type: Task Components: Misc. Connectors Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 13.0 The term swagger should no longer be prominently used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5818) separate the wildfly build/repo

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5818: ------------------------------------- Summary: separate the wildfly build/repo Key: TEIID-5818 URL: https://issues.jboss.org/browse/TEIID-5818 Project: Teiid Issue Type: Task Components: Server Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 13.0 The wildfly build should be further decoupled from the Teiid build. Initially this could be as simple as removing the module references from the parent pom. We also need to update the wildfly logic poms to start referencing teiid artifacts via a distinct version (rather than project.version). >From there we can decide how to promote it into it's own repository. As it doesn't seem likely that we'll invest in a mechanism to update teiid-wildly using some kind of teiid core overlay, we'll likely just do a teiid-wildfly release with every teiid release. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5818) separate the wildfly build/repo

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5818?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5818: ---------------------------------- Description: The wildfly build should be further decoupled from the Teiid build. Initially this could be as simple as removing the module references from the parent pom. We also need to update the wildfly logic poms to start referencing teiid artifacts via a distinct version (rather than project.version). >From there we can decide how to promote it into its own repository. As it doesn't seem likely that we'll invest in a mechanism to update teiid-wildly using some kind of teiid core overlay, we'll likely just do a teiid-wildfly release with every teiid release. was: The wildfly build should be further decoupled from the Teiid build. Initially this could be as simple as removing the module references from the parent pom. We also need to update the wildfly logic poms to start referencing teiid artifacts via a distinct version (rather than project.version). >From there we can decide how to promote it into it's own repository. As it doesn't seem likely that we'll invest in a mechanism to update teiid-wildly using some kind of teiid core overlay, we'll likely just do a teiid-wildfly release with every teiid release. > separate the wildfly build/repo > ------------------------------- > > Key: TEIID-5818 > URL: https://issues.jboss.org/browse/TEIID-5818 > Project: Teiid > Issue Type: Task > Components: Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 13.0 > > > The wildfly build should be further decoupled from the Teiid build. Initially this could be as simple as removing the module references from the parent pom. We also need to update the wildfly logic poms to start referencing teiid artifacts via a distinct version (rather than project.version). > From there we can decide how to promote it into its own repository. As it doesn't seem likely that we'll invest in a mechanism to update teiid-wildly using some kind of teiid core overlay, we'll likely just do a teiid-wildfly release with every teiid release. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5817) zero precision loaded for java.sql.Timestamp

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5817?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5817. ----------------------------------- Fix Version/s: 13.0 12.3.1 Assignee: Steven Hawkins Resolution: Done Went ahead and addressed both the parsing changes and the odata issue. In short the jdbc metadata and Teiid uses timestamp precision to mean the full width of the string. 19 characters + . + up to 9 fractional digits, so the effective default for Teiid is 29. The scale of a timestamp is meant to capture just the number of fractional seconds. On our metadata objects if both values are 0, then it's assume that we're using the default values. All of the changes were backported to 12.3.x. I'll look at bringing at least the odata change to 12.2.x > zero precision loaded for java.sql.Timestamp > -------------------------------------------- > > Key: TEIID-5817 > URL: https://issues.jboss.org/browse/TEIID-5817 > Project: Teiid > Issue Type: Bug > Components: OData, Query Engine > Reporter: Renat Eskenin > Assignee: Steven Hawkins > Priority: Major > Fix For: 13.0, 12.3.1 > > Attachments: image-2019-09-20-13-30-58-536.png, image-2019-09-20-13-34-56-255.png > > > I create spring-boot project for translate jdbc connection from vertica JDBC to odata4 REST interface. > Base project is spring-odata-example in teiid git. > When i get request to object with field witch Timestamp type i get the exception: > Request: > GET /vertica-odata-facade/odata/vertica/domain?%24top=1 > Response: > { > "error": { > "code": null, > "message": "The value '2019-09-12 09:26:22.323764' is not valid for property 'created_date'." > } > } > This field in vertica > !image-2019-09-20-13-34-56-255.png|thumbnail! > name: created_by_id > type: Timestamp > column size: 26 > decimal digits: 6 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5817) zero precision loaded for java.sql.Timestamp

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5817?page=com.atlassian.jira.plugin... ] Steven Hawkins moved TEIIDSB-118 to TEIID-5817: ----------------------------------------------- Project: Teiid (was: Teiid Spring Boot) Key: TEIID-5817 (was: TEIIDSB-118) Component/s: OData Query Engine (was: datasource) (was: OData) Affects Version/s: (was: 1.2.0) > zero precision loaded for java.sql.Timestamp > -------------------------------------------- > > Key: TEIID-5817 > URL: https://issues.jboss.org/browse/TEIID-5817 > Project: Teiid > Issue Type: Bug > Components: OData, Query Engine > Reporter: Renat Eskenin > Priority: Major > Attachments: image-2019-09-20-13-30-58-536.png, image-2019-09-20-13-34-56-255.png > > > I create spring-boot project for translate jdbc connection from vertica JDBC to odata4 REST interface. > Base project is spring-odata-example in teiid git. > When i get request to object with field witch Timestamp type i get the exception: > Request: > GET /vertica-odata-facade/odata/vertica/domain?%24top=1 > Response: > { > "error": { > "code": null, > "message": "The value '2019-09-12 09:26:22.323764' is not valid for property 'created_date'." > } > } > This field in vertica > !image-2019-09-20-13-34-56-255.png|thumbnail! > name: created_by_id > type: Timestamp > column size: 26 > decimal digits: 6 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-118) zero precision loaded for java.sql.Timestamp

by Renat Eskenin (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-118?page=com.atlassian.jira.plugi... ] Renat Eskenin commented on TEIIDSB-118: --------------------------------------- We always have 19 symbols, so it default behavior...but as you wish :) it need to analyse code. > zero precision loaded for java.sql.Timestamp > -------------------------------------------- > > Key: TEIIDSB-118 > URL: https://issues.jboss.org/browse/TEIIDSB-118 > Project: Teiid Spring Boot > Issue Type: Bug > Components: datasource, OData > Affects Versions: 1.2.0 > Reporter: Renat Eskenin > Priority: Major > Attachments: image-2019-09-20-13-30-58-536.png, image-2019-09-20-13-34-56-255.png > > > I create spring-boot project for translate jdbc connection from vertica JDBC to odata4 REST interface. > Base project is spring-odata-example in teiid git. > When i get request to object with field witch Timestamp type i get the exception: > Request: > GET /vertica-odata-facade/odata/vertica/domain?%24top=1 > Response: > { > "error": { > "code": null, > "message": "The value '2019-09-12 09:26:22.323764' is not valid for property 'created_date'." > } > } > This field in vertica > !image-2019-09-20-13-34-56-255.png|thumbnail! > name: created_by_id > type: Timestamp > column size: 26 > decimal digits: 6 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5816) DDLStringVisitor should exclude dangling foreign keys

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5816?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5816. ----------------------------------- Fix Version/s: 12.3.1 13.0 Resolution: Done Updated the logic to omit foreign keys that reference excluded tables. > DDLStringVisitor should exclude dangling foreign keys > ----------------------------------------------------- > > Key: TEIID-5816 > URL: https://issues.jboss.org/browse/TEIID-5816 > Project: Teiid > Issue Type: Task > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.3.1, 13.0 > > > For resolved metadata we should omit foreign keys that reference tables that are filtered out. > For example with > CREATE FOREIGN TABLE G1(g1e1 integer, g1e2 varchar, PRIMARY KEY(g1e1, g1e2)); > CREATE FOREIGN TABLE G2( g2e1 integer, g2e2 varchar, PRIMARY KEY(g2e1, g2e2), FOREIGN KEY (g2e1, g2e2) REFERENCES G1)); > and a filter to only include G2, we should omit the foreign key so that the returned ddl is valid. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues September 2019