[JBoss JIRA] Created: (TEIID-1335) Customer requesting the ability to make query planner always create dependent joins.
by Debbie Steigner (JIRA)
Customer requesting the ability to make query planner always create dependent joins.
------------------------------------------------------------------------------------
Key: TEIID-1335
URL: https://jira.jboss.org/browse/TEIID-1335
Project: Teiid
Issue Type: Feature Request
Components: Server
Reporter: Debbie Steigner
Assignee: Steven Hawkins
Nike is finding that the query planner often chooses to use a non-dependent join plan, even when cost statistics have been gathered on all source systems and a dependent plan would perform much better.
I've showed them how to use option makedep to force a dependent join scenario. However, it requires careful analysis of each query to setup the proper makedep parameters, and may not be feasible when working with hibernate as the client.
Thus, they ask: is there any way to tell the query planner to always use dependent join for every join, no matter what.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (TEIID-1324) Deploy JOPR Plugin on JON/RHQ
by Cristiano Nicolai (JIRA)
Deploy JOPR Plugin on JON/RHQ
-----------------------------
Key: TEIID-1324
URL: https://jira.jboss.org/browse/TEIID-1324
Project: Teiid
Issue Type: Bug
Components: Jopr Plugin
Affects Versions: 7.2
Environment: Jboss EAP 5.1, JON 2.4, jon-plugin-pack-eap-2.4.0.GA
Reporter: Cristiano Nicolai
Assignee: Steven Hawkins
When deploying Teiid JOPR plugin on JON, when the agent try to run the plugin there are some missing classes.
Caused by: java.lang.NoClassDefFoundError: org/jboss/reflect/spi/TypeInfo
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.newInstance0(Class.java:326)
at java.lang.Class.newInstance(Class.java:308)
at org.jboss.metatype.plugins.values.MetaValueFactoryBuilder$1.run(MetaValueFactoryBuilder.java:71)
at org.jboss.metatype.plugins.values.MetaValueFactoryBuilder$1.run(MetaValueFactoryBuilder.java:46)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.metatype.plugins.values.MetaValueFactoryBuilder.<clinit>(MetaValueFactoryBuilder.java:45)
at org.jboss.metatype.api.values.MetaValueFactory.<clinit>(MetaValueFactory.java:41)
at org.teiid.rhq.admin.DQPManagementView.<clinit>(DQPManagementView.java:68)
at org.teiid.rhq.plugin.VDBComponent.getAvailability(VDBComponent.java:139)
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
... 5 more
Basically the missing jar is jboss-metatype.jar.
I tried some classloader configuration including the missing jar in teiid-console-7.2.0.Beta1.jar/lib, but as it has dependent classes (jboss-managed.jar) that are loaded in jboss-as-5 RHQ plugin I couldn't find any solution without changing the jboss-as-5 code. Probably some sync with RHQ guys is needed because jboss-managed.jar depends on jboss-metatype.jar.
My workaround for this was a code change in ApplicationServerDiscoveryComponent to include the required jar from the AS installation.
private static final List<String> CLIENT_JARS = Arrays.asList(
// NOTE: The jbossall-client.jar aggregates a whole bunch of other jars from the client dir via its
// MANIFEST.MF Class-Path.
"client/jbossall-client.jar",
"client/trove.jar",
"client/javassist.jar",
"common/lib/jboss-security-aspects.jar",
"lib/jboss-managed.jar",
"lib/jboss-metatype.jar",
"lib/jboss-reflect.jar",
"lib/jboss-dependency.jar"
);
Fixing this class dependency the plugin start to require some Teiid client classes and to solve this I just copy the teiid-7.2.0.Beta1-client.jar to teiid-console-7.2.0.Beta1.jar/lib and redeploy the plugin.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (TEIID-1351) Replace translate criteria
by Steven Hawkins (JIRA)
Replace translate criteria
--------------------------
Key: TEIID-1351
URL: https://jira.jboss.org/browse/TEIID-1351
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Affects Versions: 7.3
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Critical
Fix For: 7.3
While we hardened the usage in 7.2, translate criteria has too many implied restrictions to reliably perform the update/delete the user query is specifying.
It would be better to rely on better default handling (especially pass-through) TEIID-1349 and to remove the current restrictions on virtual update, such as requiring scalar set clause values and no subquery evaluation TEIID-1276.
This change should not remove the possibility of using TRANSLATE CRITERIA/CREATE PROCEDURE, as it will not be removed until Teiid 8 or later.
Beyond the default handling, one possible construct is to provide the user with an cursor that contains the update (or delete) set with the corresponding updated values. Then leave it up to the user to iterate over the change set and process the changes. One drawback with this approach is that it may be hard to decipher from the view output rows how to apply the updates to constituent tables when the view transformation is a set or join and branch descriminators or additional primary keys are not projected. Of course those situations were already difficult to handle with translate criteria.
This will require coordinated designer changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (TEIID-1349) Better default update procedure handling
by Steven Hawkins (JIRA)
Better default update procedure handling
----------------------------------------
Key: TEIID-1349
URL: https://jira.jboss.org/browse/TEIID-1349
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Affects Versions: 7.2
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.0
We are currently very restrictive in what we can automatically handle in terms of updates procedures. Anything other than a simple non-joined select cannot have a default update procedure. We should look at expanding our default handling to simple joins and union all - along with designer warnings for derived columns or other situations that would not be automatically updatable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years