[JBoss JIRA] (TEIID-2848) MongoDB: Provide Array support
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2848?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2848:
-------------------------------------
You need to use Object[] there like
{code}
CREATE FOREIGN TABLE Customer (
customer_id integer,
FirstName varchar(25),
LastName varchar(25),
Score object[],
PRIMARY KEY (FirstName, LastName)
) OPTIONS(UPDATABLE 'TRUE');
{code}
here you can use
{code}
select * from Customer
{code}
If you want to decode the each element of the Object[] then you need to use the ARRAYTABLE, for Ex:
{code}
select c.customer_id, c.FirstName, c.LastName, x,col1, x,col2, x.col3 FROM (select customer_id, FirstName, LastName, Score) c, ARRATTABLE(c.Score COLUMNS col1 integer, col2 string, col3 double) x
{code}
If you want, you can create a view out the above SQL and normalize the schema.
> MongoDB: Provide Array support
> -------------------------------
>
> Key: TEIID-2848
> URL: https://issues.jboss.org/browse/TEIID-2848
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: CR1
> Fix For: 8.8, 8.7.1
>
>
> Provide array support for primitive data types in MongoDB translator. The arrays are supported but as embedded documents in the one-2-many situation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-2848) MongoDB: Provide Array support
by Ivan Chan (JIRA)
[ https://issues.jboss.org/browse/TEIID-2848?page=com.atlassian.jira.plugin... ]
Ivan Chan edited comment on TEIID-2848 at 9/9/14 6:38 PM:
----------------------------------------------------------
I am still a little bit confused. For example, if I have a mongodb document like the following:
{
_id: 1,
FirstName: "John",
LastName: "Doe"
Score: [89, "ninety", 91.0]
}
what should I use for database type for Score in database schema? Should I use arraytable? Like the following:
CREATE FOREIGN TABLE Customer (
customer_id integer,
FirstName varchar(25),
LastName varchar(25),
Score, arraytable,
PRIMARY KEY (FirstName, LastName)
) OPTIONS(UPDATABLE 'TRUE');
was (Author: ichanjasper):
I am still a little bit confused. For example, if I have a mongodb document like the following:
{
_id: 1,
FirstName: "John",
LastName: "Doe"
Score: [89, "ninety", 91.0]
}
what should I use for database type for Score in database schema? Should I use arraytable? Like the following:
CREATE FOREIGN array Customer (
customer_id integer,
FirstName varchar(25),
LastName varchar(25),
Score, arraytable,
PRIMARY KEY (FirstName, LastName)
) OPTIONS(UPDATABLE 'TRUE');
> MongoDB: Provide Array support
> -------------------------------
>
> Key: TEIID-2848
> URL: https://issues.jboss.org/browse/TEIID-2848
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: CR1
> Fix For: 8.8, 8.7.1
>
>
> Provide array support for primitive data types in MongoDB translator. The arrays are supported but as embedded documents in the one-2-many situation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-2848) MongoDB: Provide Array support
by Ivan Chan (JIRA)
[ https://issues.jboss.org/browse/TEIID-2848?page=com.atlassian.jira.plugin... ]
Ivan Chan commented on TEIID-2848:
----------------------------------
I am still a little bit confused. For example, if I have a mongodb document like the following:
{
_id: 1,
FirstName: "John",
LastName: "Doe"
Score: [89, "ninety", 91.0]
}
what should I use for database type for Score in database schema? Should I use arraytable? Like the following:
CREATE FOREIGN array Customer (
customer_id integer,
FirstName varchar(25),
LastName varchar(25),
Score, arraytable,
PRIMARY KEY (FirstName, LastName)
) OPTIONS(UPDATABLE 'TRUE');
> MongoDB: Provide Array support
> -------------------------------
>
> Key: TEIID-2848
> URL: https://issues.jboss.org/browse/TEIID-2848
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: CR1
> Fix For: 8.8, 8.7.1
>
>
> Provide array support for primitive data types in MongoDB translator. The arrays are supported but as embedded documents in the one-2-many situation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3116) Teiid Partial Results Mode: unavailability of datasource causes error (which is not masked)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3116?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3116:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1138679|https://bugzilla.redhat.com/show_bug.cgi?id=1138679] from NEW to ASSIGNED
> Teiid Partial Results Mode: unavailability of datasource causes error (which is not masked)
> -------------------------------------------------------------------------------------------
>
> Key: TEIID-3116
> URL: https://issues.jboss.org/browse/TEIID-3116
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
>
> Description of problem:
> Querying a vdb-table which is formed as union of two tables from different datasources. Even though "set partialresultsmode true" is run as initial query, instead of retreiving 0 rows from a datasources that is down, exception is promoted.
> Version-Release number of selected component (if applicable):
> DV 6.1 ER1
> How reproducible:
> Every time
> Steps to Reproduce:
> 1. Define one valid and one invalid datasource(invalid connection-url).
> 2. Create vdb which maps tables from both datasources.
> 3. Set partialresultsmode to true
> 4. Execute query on the given vdb-table
> Actual results:
> TeiidSQLException
> TEIID30498 Remote org.teiid.api.exception.query.QueryPlannerException: TEIID30498 Capabilities for ORBQT were not avaialable. The command could not be planned properly.
> Expected results:
> 0 rows from invalid datasource.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3119) Improve full sort performance for dup removal and grouping
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3119?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3119:
---------------------------------------
The grouping change is quite a bit more involved and will require a change the to user defined aggregate interface to work with custom functions. The basic idea is that we'll maintain a tree keyed by the ordering and expose the accumulator state to be stored along with the key. Then we'll walk the tree at the need to pull the final aggregate values. Initially we'll probably only do this in non-distinct and non-rollup scenarios - although each can be done in this manner as well with some additional effort.
> Improve full sort performance for dup removal and grouping
> ----------------------------------------------------------
>
> Key: TEIID-3119
> URL: https://issues.jboss.org/browse/TEIID-3119
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.9
>
>
> We perform a full sort for grouping/distinct reusing the existing sorting logic. This is not as efficient as it could for larger data sets with smaller numbers of groups. A hash implementation or combining the grouping with the sorting would perform better.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3106.
-----------------------------------
Labels: (was: teiid-engine)
Fix Version/s: 8.7.1
8.9
Resolution: Done
Marking as resolved based upon internal testing and user feedback.
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Fix For: 8.7.1, 8.9
>
> Attachments: BufferManagerImpl.java, BufferManagerImpl.java, CacheKey_Loog.patch, complete_log.zip, cpu monitoring.docx, dump.zip, in_local.docx, LrfuEvictionQueue.java, LrfuEvictionQueue.patch, non_high_cpu.docx
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Devesh Mishra (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Devesh Mishra commented on TEIID-3106:
--------------------------------------
We haven't seen high cpu for last two days. Looks like the solutions works perfect. Steven, do you have further commits on this ?
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java, BufferManagerImpl.java, CacheKey_Loog.patch, complete_log.zip, cpu monitoring.docx, dump.zip, in_local.docx, LrfuEvictionQueue.java, LrfuEvictionQueue.patch, non_high_cpu.docx
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months