February 2017 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4510: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1384442|https://bugzilla.redhat.com/show_bug.cgi?id=1384442] from VERIFIED to CLOSED > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3, 9.2 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > Fix For: 8.12.7.6_3, 9.2 > > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3624) No way to associate enterprise data types in dynamic vdb constructs

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3624?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3624: ------------------------------------- Do domain types only apply to the View models? I used many times the above mentioned name to class name resolution in translator code before. > No way to associate enterprise data types in dynamic vdb constructs > ------------------------------------------------------------------- > > Key: TEIID-3624 > URL: https://issues.jboss.org/browse/TEIID-3624 > Project: Teiid > Issue Type: Enhancement > Components: Grammar, Query Engine > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 9.3 > > > I don't find any doc's on how to define enterprise data types in a dynamic vdb. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4768) Clarify Caching guide using external materializaion

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4768?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4768. --------------------------------- Fix Version/s: 9.3 Resolution: Done Added description of Status table to the documentation. > Clarify Caching guide using external materializaion > --------------------------------------------------- > > Key: TEIID-4768 > URL: https://issues.jboss.org/browse/TEIID-4768 > Project: Teiid > Issue Type: Sub-task > Components: Documentation > Affects Versions: 9.3 > Reporter: Van Halbert > Assignee: Ramesh Reddy > Priority: Critical > Fix For: 9.3 > > > The caching guide section that relates to external materialization needs to add the following information for clarity: > - the TTL needs to be set at a minimum of 5 minutes (300000) so in cases where the status gets hung at "LOADING" (i.e., the target cache goes down during materialization), the materialization process will recover and restart the loading. > - add a status table "Status" matrix: > LOADED - means the cache was loaded > LOADING - means cache is in the process of loading > FAILED_LOAD - means an error occurred during the load process > ... > and these should correlate to the section that describes the process in detail. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4758) Permanent materialization load failure is when JDG source goes down

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4758?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4758: ------------------------------- Git Pull Request: (was: https://github.com/teiid/teiid/pull/903) > Permanent materialization load failure is when JDG source goes down > ------------------------------------------------------------------- > > Key: TEIID-4758 > URL: https://issues.jboss.org/browse/TEIID-4758 > Project: Teiid > Issue Type: Sub-task > Components: Server > Affects Versions: 8.12 > Reporter: Ramesh Reddy > Assignee: Van Halbert > Fix For: 9.3 > > > During the external materialization load, if the target cache database goes offline, the materialization job stops, but the {{Status}} table is left in {{LOADING}} state, which will never recover when the target cache database comes back up again. > This situation is observed when JDG is used in OpenShift along with JDV However, behavior can occur in standalone situations too. The system should resilient and must recover in this situation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4780) Clone TEIID-4734 (Backwards compatible solution)

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4780?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4780. --------------------------------- Resolution: Done > Clone TEIID-4734 (Backwards compatible solution) > ------------------------------------------------ > > Key: TEIID-4780 > URL: https://issues.jboss.org/browse/TEIID-4780 > Project: Teiid > Issue Type: Sub-task > Components: Common > Affects Versions: 9.1.2 > Reporter: Pedro Inácio > Assignee: Ramesh Reddy > Fix For: 9.2.1 > > > This is clone of TEIID-4734, however the solution provided through it is a breaking change. This JIRA is logged to provide a non-breaking change for released Teiid versions based on comments from TEIID-4734 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3624) No way to associate enterprise data types in dynamic vdb constructs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3624?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3624: --------------------------------------- With the second commit, we can correctly use domain names in cast/convert and several other places. We cannot however use them yet in: create temp table execute immediate arraytable object table text table xml table In each instance there is some existing logic that relies on the type names being the default runtime types. I'll work to relax that in subsequent commits. The javadocs and method names were updated in several places to help highlight the differing types we are dealing with. In any instance we where need the type name converted to a class there is now a method on the querymetadatainterface that will resolve against the standard type names and the domains defined in the vdb. As much as possible the Designer builtin type names are not used. > No way to associate enterprise data types in dynamic vdb constructs > ------------------------------------------------------------------- > > Key: TEIID-3624 > URL: https://issues.jboss.org/browse/TEIID-3624 > Project: Teiid > Issue Type: Enhancement > Components: Grammar, Query Engine > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 9.3 > > > I don't find any doc's on how to define enterprise data types in a dynamic vdb. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4778) External Materialization, When TTL is less than loading time, the scheduling is off

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4778?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4778. --------------------------------- Fix Version/s: 9.2.1 Resolution: Done Labels: Alpha1 (was: ) > External Materialization, When TTL is less than loading time, the scheduling is off > ----------------------------------------------------------------------------------- > > Key: TEIID-4778 > URL: https://issues.jboss.org/browse/TEIID-4778 > Project: Teiid > Issue Type: Sub-task > Components: Server > Affects Versions: 8.7 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Labels: Alpha1 > Fix For: 9.3, 9.2.1 > > > During managed external mateiralization, > 1) if the TTL specified is less than the amount of load time > 2) Then, if other nodes check the status at "LOADING", and the elapsed time is calculated from the time on the {{Status}} table. Which when goes over the TTL, it will be a negative value > 3) Then, the scheduling algorithm schedules the next check immediately, which will be exactly same as one before as it also checks from the last updated time. Thus going into a tight loop which consume all the resources spinning. > Correct this to check that, the scheduler always schedules next check atleast a default time after the previous one, which is currently at a minute. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4775) External materialization, after transaction timeout, LoadState continues to be LOADING

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4775?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4775. --------------------------------- Fix Version/s: 9.2.1 Resolution: Done Labels: Alpha1 (was: ) > External materialization, after transaction timeout, LoadState continues to be LOADING > -------------------------------------------------------------------------------------- > > Key: TEIID-4775 > URL: https://issues.jboss.org/browse/TEIID-4775 > Project: Teiid > Issue Type: Sub-task > Components: Server > Affects Versions: 8.7 > Environment: * CentOs 7 > * Teiid 9.1.2 > * Wildfly 10 > Reporter: Pedro Inácio > Assignee: Ramesh Reddy > Labels: Alpha1 > Fix For: 9.3, 9.2.1 > > > For some unknown reason, sometimes a materialized view takes more time to finish the load/update than the one defined in transaction timeout (300 seconds is the default value, and we have configured 600 seconds to try to solve the problem). > The transaction reaper will kill the update transaction. The _LoadState_ in _status_ table will be *LOADING*. > Any subsequent try to update the view will fail, since the system reads the state as being *LOADING* even if the system is not currently updating it. > Example log next. > The update took too long (more than 10 minutes [defined transaction timeout]): > {code:batch} > 2017-02-17 16:10:44,487 INFO [org.teiid.COMMAND_LOG] (NIO6) gZueFR0aNjgi START USER COMMAND: startTime=2017-02-17 16:10:44.487 requestID=gZueFR0aNjgi.11 txID=null sessionID=gZueFR0aNjgi applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql={call SYSADMIN.loadMatView(?, ?)} > 2017-02-17 16:20:44,528 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a080174:21ddbdf0:58a71a32:cb in state RUN > 2017-02-17 16:20:44,564 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff0a080174:21ddbdf0:58a71a32:cb > {code} > Next I tried to update the view: > {code:batch} > 2017-02-17 16:29:21,272 INFO [org.teiid.COMMAND_LOG] (NIO2) E1xyKpChGKvC START USER COMMAND: startTime=2017-02-17 16:29:21.272 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql=EXECUTE SYSADMIN.loadMatView('CountryServiceListCalculatedRaw','country_service_list_calculated_raw') > 2017-02-17 16:29:21,391 INFO [org.teiid.COMMAND_LOG] (Worker25_QueryProcessorQueue18136) E1xyKpChGKvC END USER COMMAND: endTime=2017-02-17 16:29:21.391 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 finalRowCount=1 > {code} > And nothing happened. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4758) Permanent materialization load failure is when JDG source goes down

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4758?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4758: ------------------------------------- [~rhn-engineering-vhalbert] The pull request is wrong, remove that, as this is specific to JDG related issue only. > Permanent materialization load failure is when JDG source goes down > ------------------------------------------------------------------- > > Key: TEIID-4758 > URL: https://issues.jboss.org/browse/TEIID-4758 > Project: Teiid > Issue Type: Sub-task > Components: Server > Affects Versions: 8.12 > Reporter: Ramesh Reddy > Assignee: Van Halbert > Fix For: 9.3 > > > During the external materialization load, if the target cache database goes offline, the materialization job stops, but the {{Status}} table is left in {{LOADING}} state, which will never recover when the target cache database comes back up again. > This situation is observed when JDG is used in OpenShift along with JDV However, behavior can occur in standalone situations too. The system should resilient and must recover in this situation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2820) Support Couchbase as a resource

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2820?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2820: ------------------------------------- Couchbase seems to be much similar to MongoDB in terms of their document storage, type of query language supported. That could be lot more work, in magnitude of multiple weeks, depending upon how deep we want to integrate. Luckily we can draw upon the ideas of MERGE, EMBEDDED from MongoDB. For simple 1 to 1 bucket/table without nesting should be little less time consuming IMO. Either case one need to get very familiar with their N1QL language. INFER seems to be logical way to go about figuring out metadata. Otherwise you would need to write similar utility anyway. See Mongo, I had to do something similar. Good thing with Teiid is you can even avoid this for time being and define the schema at Teiid layer and develop mapping semantics to Couchbase, but would need the reverse at some point in the development. Yes, we need to follow the methodology similar to Simba driver above from [3]. We could have used Simba drivers, but that does not look like Open Source drivers, and I did not find any others either. Depending upon the community interest Teiid can be of good play in providing Open Source driver IMO. Also see [4] I would also poke the Couchbase community for any interest in opsn source JDBC/ODBC driver for this? May be someone with experience can help with our effort? [4] http://docs.couchbase.com/admin/admin/Views/views-translateSQL.html > Support Couchbase as a resource > ------------------------------- > > Key: TEIID-2820 > URL: https://issues.jboss.org/browse/TEIID-2820 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Kim Palko > Assignee: Kylin Soong > Priority: Blocker > Labels: data_source > Fix For: 9.3 > > > Support Couchbase as a data source in Teiid. This requires resource adapter and translater development -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2017