[JBoss JIRA] (TEIID-3111) Expose group name, defined for functions, in the exposed metadata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3111?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3111:
---------------------------------------
That's not the intention of the logic, but it looks like the FunctionTree code will only create resolving entries for the top level and n-1 levels of the function name. So we see
SYS.JCR.JCR*
JCR.JCR*
but no
JCR*
> Expose group name, defined for functions, in the exposed metadata
> -----------------------------------------------------------------
>
> Key: TEIID-3111
> URL: https://issues.jboss.org/browse/TEIID-3111
> Project: Teiid
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.9
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> When a function has a defined group, like JCR for the modeshape functions, it should be exposed somehow in the metadata. Otherwise, user will never know to use the group name (i.e., JCR.JCR_ISCHILDNODE(rc."jcr:path", rt."jcr:path") ) unless they goto the documentation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3038) Add spatial query support to the Teiid MongoDB translator
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3038?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3038.
---------------------------------
Labels: Beta1 (was: )
Resolution: Done
Changed the function parameter types on all $geo functions to "double" from big integer. So to issue a query user needs to use format like
{code}
SELECT * FROM tracks WHERE mongo.geoIntersects(loc, 'Polygon', ((cast(-77.800884 as double), cast(43.300259 as double)), (cast(-77.794790 as double), cast(43.300259 as double)), (cast(-77.794790 as double), cast(43.297886 as double)), (cast(-77.800884 as double), cast(43.297886 as double)), (cast(-77.800884 as double), cast(43.300259 as double))))
{code}
> Add spatial query support to the Teiid MongoDB translator
> ---------------------------------------------------------
>
> Key: TEIID-3038
> URL: https://issues.jboss.org/browse/TEIID-3038
> Project: Teiid
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Misc. Connectors
> Affects Versions: 8.8
> Reporter: Michael Farwell
> Assignee: Ramesh Reddy
> Labels: Beta1
> Fix For: 8.7.1, 8.9
>
>
> We'd like to be able to issue geoIntersects and geoWithin queries through the MongoDB translator. See comment below on a proposed approach.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3111) Expose group name, defined for functions, in the exposed metadata
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3111?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3111:
------------------------------------
And TEIID-3098 is about exposing the procedures in the metadata so that they show up in the model when its imported.
> Expose group name, defined for functions, in the exposed metadata
> -----------------------------------------------------------------
>
> Key: TEIID-3111
> URL: https://issues.jboss.org/browse/TEIID-3111
> Project: Teiid
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.9
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> When a function has a defined group, like JCR for the modeshape functions, it should be exposed somehow in the metadata. Otherwise, user will never know to use the group name (i.e., JCR.JCR_ISCHILDNODE(rc."jcr:path", rt."jcr:path") ) unless they goto the documentation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3110) name in source should not be omitted in ddl
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3110?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3110:
---------------------------------------
Looking at this further it seems the only safe change is to not omit the name in source and update all of the appropriate logic to optionally use the name in source. We'll then leave the ldap logic as is.
> name in source should not be omitted in ddl
> -------------------------------------------
>
> Key: TEIID-3110
> URL: https://issues.jboss.org/browse/TEIID-3110
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Affects Versions: 8.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.9
>
>
> When creating the ddl string we'll omit the name in source if it matches the table name. While this is valid for several translators (jdbc, object, mongodb, and others), it is not valid for all - salesforce, ldap, odata, and others.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3111) Expose group name, defined for functions, in the exposed metadata
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3111?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3111:
------------------------------------
I think its different, and applies to all pushdown functions with a defined group.
In the factory, define the pushdown function:
addPushDownFunction(JCR, JCR_ISCHILDNODE, BOOLEAN, STRING, STRING);
As indicated, it has "JCR" group defined.
And in order to execute the function, it has to be qualified with the group.
Example: JCR.JCR_ISCHILDNODE(rc."jcr:path", rt."jcr:path")
It will not execute without the "JCR." prefix.
> Expose group name, defined for functions, in the exposed metadata
> -----------------------------------------------------------------
>
> Key: TEIID-3111
> URL: https://issues.jboss.org/browse/TEIID-3111
> Project: Teiid
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.9
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> When a function has a defined group, like JCR for the modeshape functions, it should be exposed somehow in the metadata. Otherwise, user will never know to use the group name (i.e., JCR.JCR_ISCHILDNODE(rc."jcr:path", rt."jcr:path") ) unless they goto the documentation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3098) Expose the ModeShape JCR functions in the modeshape translator metadata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3098?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3098:
---------------------------------------
Just to clarify we have two types of source functions:
-those that are schema scoped and exposed via the native metadata load
-pushdown functions that are exposed for all instances of the translator under as pseudo system function
The differentiation is so that we know that the definitions of the pushdown functions are shared.
So what are you looking to expose here?
> Expose the ModeShape JCR functions in the modeshape translator metadata
> ------------------------------------------------------------------------
>
> Key: TEIID-3098
> URL: https://issues.jboss.org/browse/TEIID-3098
> Project: Teiid
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> Expose the ModeShape JCR functions in the metadata in the modeshape translator.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3111) Expose group name, defined for functions, in the exposed metadata
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3111?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3111:
-------------------------------------
So JCR is group, and "JCR_ISCHILDNODE" is function name? what does "JCR.JCR_ISCHILDNODE" account to?
> Expose group name, defined for functions, in the exposed metadata
> -----------------------------------------------------------------
>
> Key: TEIID-3111
> URL: https://issues.jboss.org/browse/TEIID-3111
> Project: Teiid
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.9
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> When a function has a defined group, like JCR for the modeshape functions, it should be exposed somehow in the metadata. Otherwise, user will never know to use the group name (i.e., JCR.JCR_ISCHILDNODE(rc."jcr:path", rt."jcr:path") ) unless they goto the documentation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (TEIID-3111) Expose group name, defined for functions, in the exposed metadata
by Van Halbert (JIRA)
Van Halbert created TEIID-3111:
----------------------------------
Summary: Expose group name, defined for functions, in the exposed metadata
Key: TEIID-3111
URL: https://issues.jboss.org/browse/TEIID-3111
Project: Teiid
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Server
Affects Versions: 8.9
Reporter: Van Halbert
Assignee: Steven Hawkins
When a function has a defined group, like JCR for the modeshape functions, it should be exposed somehow in the metadata. Otherwise, user will never know to use the group name (i.e., JCR.JCR_ISCHILDNODE(rc."jcr:path", rt."jcr:path") ) unless they goto the documentation.
--
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 commented on TEIID-3106:
---------------------------------------
It's possible that the integer casts (also removed in the previous patch) were causing negative values to be introduced, which could have converged on larger negative values for the ordering value. But that would imply that more than 2 billion reads had occurred, which seems unlikely for start up.
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java, CacheKey_Loog.patch
>
>
> 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