March 2013 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2452) Oracle pushdown of like_regex is incorrect

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2452?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2452. ----------------------------------- Resolution: Done corrected the syntax > Oracle pushdown of like_regex is incorrect > ------------------------------------------ > > Key: TEIID-2452 > URL: https://issues.jboss.org/browse/TEIID-2452 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 7.5 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4 > > > The pushdown for oracle needs to use function notation, rather than an infix operator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2452) Oracle pushdown of like_regex is incorrect

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2452: ------------------------------------- Summary: Oracle pushdown of like_regex is incorrect Key: TEIID-2452 URL: https://issues.jboss.org/browse/TEIID-2452 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 7.5 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.4 The pushdown for oracle needs to use function notation, rather than an infix operator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2435) Calling getCacheStats("QUERY_SERVICE_RESULT_SET_CACHE") produces IllegalArgumentException

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-2435?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-2435: ------------------------------------ Is this being fixed in https://issues.jboss.org/browse/TEIID-2408 > Calling getCacheStats("QUERY_SERVICE_RESULT_SET_CACHE") produces IllegalArgumentException > ----------------------------------------------------------------------------------------- > > Key: TEIID-2435 > URL: https://issues.jboss.org/browse/TEIID-2435 > Project: Teiid > Issue Type: Bug > Components: AdminApi > Affects Versions: 8.3 > Reporter: Van Halbert > Assignee: Ramesh Reddy > Fix For: 8.4 > > Attachments: CacheStats.groovy > > > Making the following groovy script call using adminshell: > CacheStatistics startCache > try { > startCache = getCacheStats("QUERY_SERVICE_RESULT_SET_CACHE") > } > catch ( Exception e ) { > println( "Exception: " + e.getMessage() ) > } > > produces this error: Exception: TEIID70013 java.lang.IllegalArgumentException > see attachment for groovy script that was run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2408) statistics of teiid query queuing information

by Jack Ma (JIRA)

[ https://issues.jboss.org/browse/TEIID-2408?page=com.atlassian.jira.plugin... ] Jack Ma reopened TEIID-2408: ---------------------------- Hi Ramesh: I am trying to verify this issue at 8.3 teiid final release. When I try to retrieve the engineStatistics, I got following exception: Caused by: java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.getChild(ModelValue.java:108) at org.jboss.dmr.PropertyModelValue.getChild(PropertyModelValue.java:116) at org.jboss.dmr.ModelNode.get(ModelNode.java:798) at org.teiid.adminapi.impl.VDBMetadataMapper$EngineStatisticsMetadataMapper.unwrap(VDBMetadataMapper.java:1014) at org.teiid.adminapi.impl.VDBMetadataMapper$EngineStatisticsMetadataMapper.unwrap(VDBMetadataMapper.java:973) at org.teiid.adminapi.AdminFactory$AdminImpl.getList(AdminFactory.java:1389) at org.teiid.adminapi.AdminFactory$AdminImpl.getDomainAwareList(AdminFactory.java:1376) at org.teiid.adminapi.AdminFactory$AdminImpl.getEngineStats(AdminFactory.java:784) By debugging a little bit of teiid source code: at AdminFactory$AdminImpl.getList(ModelNode, MetadataMapper<T>), we try to from operationResult to create a list of node for each field of results. then to unwrap the each node individually. soat VDBMetadataMapper$EngineStatisticsMetadataMapper.unwrap(ModelNode), input ModelNode parameter only contains one field of engine statistic results each time, for example, it only has a node contains "Session-count", but teiid is trying to get all other engine statistics which does not exist in this individual node. So exception occurred. Therefore I re-opened this issue. Please confirm it. Thanks Jack > statistics of teiid query queuing information > --------------------------------------------- > > Key: TEIID-2408 > URL: https://issues.jboss.org/browse/TEIID-2408 > Project: Teiid > Issue Type: Feature Request > Components: AdminApi > Affects Versions: 8.2 > Reporter: Jack Ma > Assignee: Ramesh Reddy > Fix For: 8.3 > > > At currently version of teiid, there is no teiid queuing information available from either teiid api or log or jmx, like how many query plans are still in the waiting queue, how many are in the active queue etc. .Thinking those queuing information is pretty critical for performance tuning up, > Based on the Ramesh's suggestion, creating this request for probably a statistics max water mark in the waiting queue, and average time spent in waiting queue etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2451) Break out VDB Translator Overrides and Models into a Separate Resource

by Ted Jones (JIRA)

Ted Jones created TEIID-2451: -------------------------------- Summary: Break out VDB Translator Overrides and Models into a Separate Resource Key: TEIID-2451 URL: https://issues.jboss.org/browse/TEIID-2451 Project: Teiid Issue Type: Feature Request Components: RHQ Affects Versions: 8.3 Reporter: Ted Jones Assignee: Ted Jones Fix For: 8.4 Currently, models and translator overrides display and the VDB configuration page. If we break them out as a separate resource, they will display as folders under the VDB resource which will be cleaner than having everything on one tab. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2445) vdb.xml usability enhancements

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2445?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2445. ----------------------------------- Resolution: Done effectively replaced UseConnectorMetadata with cache-metadata and supports-multi-source-bindings with multisource and updated the release notes / docs appropriately. > vdb.xml usability enhancements > ------------------------------ > > Key: TEIID-2445 > URL: https://issues.jboss.org/browse/TEIID-2445 > Project: Teiid > Issue Type: Enhancement > Components: Server > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > Fix For: 8.4 > > > Couple of usability enhancements need to be done on the -vdb.xml to make the intent clear > UseConnectorMetadata=true/cached > - The true case could be removed entirely. The notion of metadata caching could be handled by a model property and should probably be more baked into the MetadataRepository facility (such as passing the cached metadata in for update). > supports-multi-source-bindings=true/false > - Since we have mostly removed the binding terminology, it would make more sense to call this just multi-source or multisource (which is consistent with the multisource.columnName and addColumn properties). We could also automatically infer it to be true when there are multiple sources listed for a single model (which is currently an error case without this property) so that it would only be needed if you wanted a single source to appear as if it were a multisource model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2449) Allow for a vdb zip to store ddl outside of the vdb.xml

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2449?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2449: --------------------------------------- The initial check-in adds VDBResource instances available via the MetadataFactory.getVDBResources for use by metadata repositories. Another approach would be to make the resources available via the VDB, but that didn't seem appropriate given the remote usages. A DDL-FILE repository was added that uses the metadata text to specify the location of the ddl file, which will be an absolute path relative to the root of the vdb zip. The index logic was further refactored to remove unnecessary code, mostly related to update/save functionality and to remove the dependency on VirtualFile. Also converted the IndexMetadataStore/IndexMetadataRepository into a single IndexMetadataRepository class. This should address an issue where enterprise types from index vdbs are not be added into the metadatastore, since we were only setting the Schema. > Allow for a vdb zip to store ddl outside of the vdb.xml > ------------------------------------------------------- > > Key: TEIID-2449 > URL: https://issues.jboss.org/browse/TEIID-2449 > Project: Teiid > Issue Type: Feature Request > Components: Server > Reporter: Steven Hawkins > Fix For: 8.4 > > > Our current vdb.xml design will include the ddl metadata string in-memory which is not desirable for large metadata sets. We should provide a built-in mechanism to relocate the metadata to separate files in a zip (which can also be a natural replacement for index files when the designer is ready). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2450) Like criteria with 'Z' before wildcards throw an exception

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2450?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2450: --------------------------------------- > But there should be some reason for creating submap. I guess it's speed, am I right? Yes the whole point is to avoid full scans when possible regardless of whether we're targeting a real table or a memory backed construct like the system tables. > So it would be great to have that submap work right if it isn't a complex task. It is working as intended. > If you look at ASCII table you'll see that characters follow in such order: Yes, I am aware of the character ordering. Here again it does not matter if if ^ _ etc. are initially included in the submap. What matters is that the partial prefix matching reduces the amount of the table that we scan. > Like criteria with 'Z' before wildcards throw an exception > ---------------------------------------------------------- > > Key: TEIID-2450 > URL: https://issues.jboss.org/browse/TEIID-2450 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.2 > Reporter: Paul Lysak > Assignee: Steven Hawkins > Fix For: 8.4 > > > If query contains letter 'Z' before wildcard (for example, query contains following part: MY_COLUMN LIKE 'BAZ_BAR') then exception is thrown: > Caused by: java.lang.IllegalArgumentException: fromKey > toKey > at java.util.TreeMap$NavigableSubMap.<init>(TreeMap.java:1240) > ... > at org.teiid.dqp.internal.process.RecordTable.processQuery(RecordTable.java:189) > ... > > The reason of the problem is following. > BaseIndexInfo.processCriteria() in order to build "less then" conditon from LIKE increments the code of last character in condition prefix: > this.addCondition(i, new Constant(prefix.substring(0, prefix.length() -1) + (char) (prefix.charAt(prefix.length()-1)+1)), CompareCriteria.LE); > If prefix happens to end in uppercase letter 'Z' then after increment it becomes '['. > But TempMetadataStore uses String.CaseInsensitiveComparator: > public TempMetadataStore() { > this(new TreeMap<String, TempMetadataID>(String.CASE_INSENSITIVE_ORDER)); > } > And String API documentation clearly says that comparison is performed against lowercase versions. Therefore 'Z' is converted to 'z'. > And later when trying to get subtree with lower bound = 'Z' and upper bound = '[' and exception is thrown because in fact 'z' is lesser then '[' > Other than this exception it also has another problem. If we do query MY_COLUMN LIKE 'BA@_BAR' then upper condition would be 'A' (next character after '@'). > But due to lowercase comparison it will be converted to 'a', so values like 'BAB_BAR', 'BAC_BAR', ... 'BA^_BAR' all would be returned because 'B', 'C', ..., '^' are between '@' and 'a'. > I suggest either using case sensitive map (with prior conversion of all values to upper case) or converting values in BaseIndexInfo.processCriteria() into lower case. > I also worry about CompareCriteria.LE in BaseIndexInfo.processCriteria(). Shouldn't it be strictly less? with less or equal when querying 'AAA_' you will get 'AAB_' values as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2450) Like criteria with 'Z' before wildcards throw an exception

by Paul Lysak (JIRA)

[ https://issues.jboss.org/browse/TEIID-2450?page=com.atlassian.jira.plugin... ] Paul Lysak commented on TEIID-2450: ----------------------------------- In practice I've only faced the problem with 'Z'. Other issues are merely hypotetical - what I've spotted from the code. If there is some post-query check that eliminates items that don't satisfy LIKE condition then it should be OK. But there should be some reason for creating submap. I guess it's speed, am I right? So it would be great to have that submap work right if it isn't a complex task. If you look at ASCII table you'll see that characters follow in such order: ... @ A B ... Y Z [ \ ] ^ _ ` a b ... y z { | } ~ I agree that B, C, ... Z will not get into submap with lowercase comparison, that was my mistake. But characters [ \ ] ^ _ ` still will be there. Thanks for your effort! > Like criteria with 'Z' before wildcards throw an exception > ---------------------------------------------------------- > > Key: TEIID-2450 > URL: https://issues.jboss.org/browse/TEIID-2450 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.2 > Reporter: Paul Lysak > Assignee: Steven Hawkins > Fix For: 8.4 > > > If query contains letter 'Z' before wildcard (for example, query contains following part: MY_COLUMN LIKE 'BAZ_BAR') then exception is thrown: > Caused by: java.lang.IllegalArgumentException: fromKey > toKey > at java.util.TreeMap$NavigableSubMap.<init>(TreeMap.java:1240) > ... > at org.teiid.dqp.internal.process.RecordTable.processQuery(RecordTable.java:189) > ... > > The reason of the problem is following. > BaseIndexInfo.processCriteria() in order to build "less then" conditon from LIKE increments the code of last character in condition prefix: > this.addCondition(i, new Constant(prefix.substring(0, prefix.length() -1) + (char) (prefix.charAt(prefix.length()-1)+1)), CompareCriteria.LE); > If prefix happens to end in uppercase letter 'Z' then after increment it becomes '['. > But TempMetadataStore uses String.CaseInsensitiveComparator: > public TempMetadataStore() { > this(new TreeMap<String, TempMetadataID>(String.CASE_INSENSITIVE_ORDER)); > } > And String API documentation clearly says that comparison is performed against lowercase versions. Therefore 'Z' is converted to 'z'. > And later when trying to get subtree with lower bound = 'Z' and upper bound = '[' and exception is thrown because in fact 'z' is lesser then '[' > Other than this exception it also has another problem. If we do query MY_COLUMN LIKE 'BA@_BAR' then upper condition would be 'A' (next character after '@'). > But due to lowercase comparison it will be converted to 'a', so values like 'BAB_BAR', 'BAC_BAR', ... 'BA^_BAR' all would be returned because 'B', 'C', ..., '^' are between '@' and 'a'. > I suggest either using case sensitive map (with prior conversion of all values to upper case) or converting values in BaseIndexInfo.processCriteria() into lower case. > I also worry about CompareCriteria.LE in BaseIndexInfo.processCriteria(). Shouldn't it be strictly less? with less or equal when querying 'AAA_' you will get 'AAB_' values as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2449) Allow for a vdb zip to store ddl outside of the vdb.xml

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2449?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2449: --------------------------------------- The basic approach here will be to elevate the concept of the vdb resource map into a first class citizen that will be available during the metadata load. Then all special handling related to index metadata can be removed. However for backwards compatibility we'll probably have to assume that any vdb with indexes should assume that the indexmetadatarepository is the default (which is the current handling). A new metadata repository type "ddl-file" would need to be created that could be used in a zip to reference the appropriate zip file resource. > Allow for a vdb zip to store ddl outside of the vdb.xml > ------------------------------------------------------- > > Key: TEIID-2449 > URL: https://issues.jboss.org/browse/TEIID-2449 > Project: Teiid > Issue Type: Feature Request > Components: Server > Reporter: Steven Hawkins > Fix For: 8.4 > > > Our current vdb.xml design will include the ddl metadata string in-memory which is not desirable for large metadata sets. We should provide a built-in mechanism to relocate the metadata to separate files in a zip (which can also be a natural replacement for index files when the designer is ready). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2013